From nanog at grrrrreg.net Mon Sep 1 01:19:24 2008 From: nanog at grrrrreg.net (Greg VILLAIN) Date: Mon, 1 Sep 2008 08:19:24 +0200 Subject: Force10 Gear - Opinions In-Reply-To: References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <48B41978.9040201@sprunk.org> Message-ID: On Aug 26, 2008, at 6:46 PM, Owen DeLong wrote: > > Another thing to note (as near as I can tell, this applies to all > vendors). All line cards will function > only at the lowest common denominator line card CAM level. > > IOW, if you have single, dual, and quad-cam cards in your F10 > chassis, they'll all act like > single-CAM cards. > > Owen I'd have to second that. This is a very annoying fact, that you will find mentioned nowhere. What I also used to dislike is the lack of verbosity of 'show features' - but that was back a year ago. Btw, you absolutely want to avoid the S series, the CLI is a pain, and is not the same as the E or C series, and lacks many features. Price/10G port is interesting though, but not as much as with Arastra, if that's switching you're into. (never tested any such kits though...) My own 2 cents. Greg VILLAIN From fergdawg at netzero.net Mon Sep 1 03:48:12 2008 From: fergdawg at netzero.net (Paul Ferguson) Date: Mon, 1 Sep 2008 08:48:12 GMT Subject: GLBX De-Peers Intercage [Was: RE: Washington Post: Atrivo/Intercag e, w hy are we peering with the American RBN?] Message-ID: <20080901.014812.9559.0@webmail03.vgs.untd.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- "Paul Ferguson" wrote: >-- "Marc Sachs" wrote: >>http://cidr-report.org/cgi-bin/as-report?as=AS27595&v=4&view=2.0 > >My only concern here is that by the publicity this issue continues >to receive, these activities will just move else where, like >scurrying cockroaches (like what happened with AS40989). > [some elided] I guess my effort to evoke commentary on NANOG failed. My next question to the peanut gallery is: What do you suggest we should do on other hosting IP blocks are are continuing to host criminal activity, even in the face of abuse reports, etc.? Seriously -- I think this is an issue which needs to be addressed here. ISPs cannot continue to sweep this issue under the proverbial carpet. Is this an issue that network operations folk don't really care about? - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFIu6xHq1pz9mNUZTMRAo1gAKCT0QCc65W1z8C5gsegsm6zBWDDCwCeLKac 7nVL8XmqOZiFfD18hFSFL/M= =8pXG -----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 Valdis.Kletnieks at vt.edu Mon Sep 1 04:36:47 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 01 Sep 2008 05:36:47 -0400 Subject: GLBX De-Peers Intercage [Was: RE: Washington Post: Atrivo/Intercag e, w hy are we peering with the American RBN?] In-Reply-To: Your message of "Mon, 01 Sep 2008 08:48:12 -0000." <20080901.014812.9559.0@webmail03.vgs.untd.com> References: <20080901.014812.9559.0@webmail03.vgs.untd.com> Message-ID: <7679.1220261807@turing-police.cc.vt.edu> On Mon, 01 Sep 2008 08:48:12 -0000, Paul Ferguson said: > My next question to the peanut gallery is: What do you > suggest we should do on other hosting IP blocks are are continuing > to host criminal activity, even in the face of abuse reports, etc.? > > Seriously -- I think this is an issue which needs to be addressed > here. ISPs cannot continue to sweep this issue under the proverbial > carpet. > > Is this an issue that network operations folk don't really care > about? If somebody's paying you $n/megabyte for transit/connectivity, what's your incentive to make them clean up their act and get rid of their P2P filesharing traffic, spam traffic, and so on? Serious question, that - how many long-haul providers would be in serious trouble if all the spam and filesharing suddenly stopped and only legitimate traffic travelled through their pipes? -------------- 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 Mon Sep 1 04:53:22 2008 From: ge at linuxbox.org (Gadi Evron) Date: Mon, 1 Sep 2008 04:53:22 -0500 (CDT) Subject: GLBX De-Peers Intercage [Was: RE: Washington Post: Atrivo/Intercag e, w hy are we peering with the American RBN?] In-Reply-To: <20080901.014812.9559.0@webmail03.vgs.untd.com> References: <20080901.014812.9559.0@webmail03.vgs.untd.com> Message-ID: On Mon, 1 Sep 2008, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > - -- "Paul Ferguson" wrote: > >> -- "Marc Sachs" wrote: > >>> http://cidr-report.org/cgi-bin/as-report?as=AS27595&v=4&view=2.0 > >> >> My only concern here is that by the publicity this issue continues >> to receive, these activities will just move else where, like >> scurrying cockroaches (like what happened with AS40989). >> > > [some elided] > > I guess my effort to evoke commentary on NANOG failed. > > My next question to the peanut gallery is: What do you > suggest we should do on other hosting IP blocks are are continuing > to host criminal activity, even in the face of abuse reports, etc.? > > Seriously -- I think this is an issue which needs to be addressed > here. ISPs cannot continue to sweep this issue under the proverbial > carpet. > > Is this an issue that network operations folk don't really care > about? NANOG is on vacation. Wait one more day. :) > - - ferg > > -----BEGIN PGP SIGNATURE----- > Version: PGP Desktop 9.6.3 (Build 3017) > > wj8DBQFIu6xHq1pz9mNUZTMRAo1gAKCT0QCc65W1z8C5gsegsm6zBWDDCwCeLKac > 7nVL8XmqOZiFfD18hFSFL/M= > =8pXG > -----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 bmanning at vacation.karoshi.com Mon Sep 1 04:55:46 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 1 Sep 2008 09:55:46 +0000 Subject: GLBX De-Peers Intercage [Was: RE: Washington Post: Atrivo/Intercag e, w hy are we peering with the American RBN?] In-Reply-To: <7679.1220261807@turing-police.cc.vt.edu> References: <20080901.014812.9559.0@webmail03.vgs.untd.com> <7679.1220261807@turing-police.cc.vt.edu> Message-ID: <20080901095546.GA23397@vacation.karoshi.com.> On Mon, Sep 01, 2008 at 05:36:47AM -0400, Valdis.Kletnieks at vt.edu wrote: > > Serious question, that - how many long-haul providers would be in serious > trouble if all the spam and filesharing suddenly stopped and only legitimate > traffic travelled through their pipes? define "legitimate" --bill From fweimer at bfk.de Mon Sep 1 04:58:54 2008 From: fweimer at bfk.de (Florian Weimer) Date: Mon, 01 Sep 2008 11:58:54 +0200 Subject: GLBX De-Peers Intercage In-Reply-To: <20080901095546.GA23397@vacation.karoshi.com.> (bmanning@vacation.karoshi.com's message of "Mon, 1 Sep 2008 09:55:46 +0000") References: <20080901.014812.9559.0@webmail03.vgs.untd.com> <7679.1220261807@turing-police.cc.vt.edu> <20080901095546.GA23397@vacation.karoshi.com.> Message-ID: <82ljycjig1.fsf@mid.bfk.de> * > On Mon, Sep 01, 2008 at 05:36:47AM -0400, Valdis.Kletnieks at vt.edu wrote: >> >> Serious question, that - how many long-haul providers would be in serious >> trouble if all the spam and filesharing suddenly stopped and only legitimate >> traffic travelled through their pipes? > > define "legitimate" Traffic in accordance with their AUP. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From ww at styx.org Mon Sep 1 05:00:28 2008 From: ww at styx.org (William Waites) Date: Mon, 1 Sep 2008 12:00:28 +0200 Subject: GLBX De-Peers Intercage In-Reply-To: <20080901.014812.9559.0@webmail03.vgs.untd.com> References: <20080901.014812.9559.0@webmail03.vgs.untd.com> Message-ID: <776398FC-BFA7-4555-B2E0-36E03BC7D714@styx.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 08-09-01 ? 10:48, Paul Ferguson a ?crit : > My next question to the peanut gallery is: What do you > suggest we should do on other hosting IP blocks are are continuing > to host criminal activity, even in the face of abuse reports, etc.? As mentioned in private email, I think where there is *evidence* of *criminal* activity, show this to a judge, get the judge to order ARIN to revoke the ASN/netblock, the traffic then becomes bogon and can/ should be filtered. If there can be a legal procedure established for this it may even be able to be done quickly in specific instances. Of course a parallel procedure would be necessary for each bit of the ROW.. - -w - -- William Waites http://www.irl.styx.org/ +49 30 8894 9942 CD70 0498 8AE4 36EA 1CD7 281C 427A 3F36 2130 E9F5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAki7vTwACgkQQno/NiEw6fXGVQCgqMoZNjIp5pfPracBrNfFo61g dN8AoKi+f6H7iWgNrG/OIL8yG6WmmTw1 =roam -----END PGP SIGNATURE----- From adrian at creative.net.au Mon Sep 1 05:18:25 2008 From: adrian at creative.net.au (Adrian Chadd) Date: Mon, 1 Sep 2008 18:18:25 +0800 Subject: GLBX De-Peers Intercage In-Reply-To: <776398FC-BFA7-4555-B2E0-36E03BC7D714@styx.org> References: <20080901.014812.9559.0@webmail03.vgs.untd.com> <776398FC-BFA7-4555-B2E0-36E03BC7D714@styx.org> Message-ID: <20080901101825.GH19179@skywalker.creative.net.au> On Mon, Sep 01, 2008, William Waites wrote: > As mentioned in private email, I think where there is *evidence* of > *criminal* activity, show this to a judge, get the judge to order ARIN > to revoke the ASN/netblock, the traffic then becomes bogon and can/ > should be filtered. Oh come on, how quickly would that migrate to enforcing copyright infringement? Or if you're especially evil, used by larger companies to bully smaller companies out of precious IPv4 space? I reckon having your IPv4 space revoked for more than a few hours would upset most if not all small players. Please find an alternative method of tidying up the trash and don't stir that nest of hornets. Adrian From ge at linuxbox.org Mon Sep 1 05:28:18 2008 From: ge at linuxbox.org (Gadi Evron) Date: Mon, 1 Sep 2008 05:28:18 -0500 (CDT) Subject: GLBX De-Peers Intercage In-Reply-To: <20080901101825.GH19179@skywalker.creative.net.au> References: <20080901.014812.9559.0@webmail03.vgs.untd.com> <776398FC-BFA7-4555-B2E0-36E03BC7D714@styx.org> <20080901101825.GH19179@skywalker.creative.net.au> Message-ID: On Mon, 1 Sep 2008, Adrian Chadd wrote: > On Mon, Sep 01, 2008, William Waites wrote: > >> As mentioned in private email, I think where there is *evidence* of >> *criminal* activity, show this to a judge, get the judge to order ARIN >> to revoke the ASN/netblock, the traffic then becomes bogon and can/ >> should be filtered. Proving criminal activity is for law enforcement. Maintaining our networks against DDoS and our customers against being massively compromised, now that's something else. If a layer had become _that_bad_ I don't want them communicating with me, and if I am their peer, I don't want to peer with them. It's an individual choice by each provider, and we can lok at them in any light we like. > Oh come on, how quickly would that migrate to enforcing copyright Copyright is a legal issue which does not trouble our networks, so if you get a legal paper asking you to do so, it's a whole other business. Don't muddy the water. The issue is complicated enough as it is: do we want such dirty providers to massively compromise the Internet, our customers, or through us? Different answers from different people. If law enforcement was capable of doing the job, we wouldn't have had to discuss this. > infringement? Or if you're especially evil, used by larger companies > to bully smaller companies out of precious IPv4 space? > > I reckon having your IPv4 space revoked for more than a few hours would > upset most if not all small players. > > Please find an alternative method of tidying up the trash and don't > stir that nest of hornets. > > > > Adrian > > From ww at styx.org Mon Sep 1 05:31:43 2008 From: ww at styx.org (William Waites) Date: Mon, 1 Sep 2008 12:31:43 +0200 Subject: GLBX De-Peers Intercage In-Reply-To: <20080901101825.GH19179@skywalker.creative.net.au> References: <20080901.014812.9559.0@webmail03.vgs.untd.com> <776398FC-BFA7-4555-B2E0-36E03BC7D714@styx.org> <20080901101825.GH19179@skywalker.creative.net.au> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 08-09-01 ? 12:18, Adrian Chadd a ?crit : > Oh come on, how quickly would that migrate to enforcing copyright > infringement? Or if you're especially evil, used by larger companies > to bully smaller companies out of precious IPv4 space? With appropriate controls. For example that the entity in question exists entirely or substantially for illegal purposes. Illegal does not mean "in violation of an agreement", rather "against the law". And such an action should not be possible for a private person to bring. > Please find an alternative method of tidying up the trash and don't > stir that nest of hornets. Workeable suggestions? So far I've seen, * organized shunning * BGP blacklists Cheers, - -w - -- William Waites http://www.irl.styx.org/ +49 30 8894 9942 CD70 0498 8AE4 36EA 1CD7 281C 427A 3F36 2130 E9F5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAki7xI8ACgkQQno/NiEw6fXvfgCeO4X0qbRg05VPCMC4jesmvFMd dRAAniTVdxJEVx6ecR+C1Br2INpYJ2pe =6zQj -----END PGP SIGNATURE----- From ge at linuxbox.org Mon Sep 1 05:34:49 2008 From: ge at linuxbox.org (Gadi Evron) Date: Mon, 1 Sep 2008 05:34:49 -0500 (CDT) Subject: GLBX De-Peers Intercage In-Reply-To: References: <20080901.014812.9559.0@webmail03.vgs.untd.com> <776398FC-BFA7-4555-B2E0-36E03BC7D714@styx.org> <20080901101825.GH19179@skywalker.creative.net.au> Message-ID: On Mon, 1 Sep 2008, William Waites wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Le 08-09-01 ? 12:18, Adrian Chadd a ?crit : > >> Oh come on, how quickly would that migrate to enforcing copyright >> infringement? Or if you're especially evil, used by larger companies >> to bully smaller companies out of precious IPv4 space? > > With appropriate controls. For example that the entity in question exists > entirely or substantially for illegal purposes. Illegal does not mean "in > violation of an agreement", rather "against the law". And such an action > should not be possible for a private person to bring. > >> Please find an alternative method of tidying up the trash and don't >> stir that nest of hornets. > > > Workeable suggestions? So far I've seen, > > * organized shunning > * BGP blacklists I can see the "don't be the Internet's firewall" bunch jumping up and out of their seats, spilling their coffees. How dare you destroy so many keyboards? :) > Cheers, > - -w > - -- > William Waites > http://www.irl.styx.org/ +49 30 8894 9942 > CD70 0498 8AE4 36EA 1CD7 281C 427A 3F36 2130 E9F5 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (Darwin) > > iEYEARECAAYFAki7xI8ACgkQQno/NiEw6fXvfgCeO4X0qbRg05VPCMC4jesmvFMd > dRAAniTVdxJEVx6ecR+C1Br2INpYJ2pe > =6zQj > -----END PGP SIGNATURE----- > > From ww at styx.org Mon Sep 1 05:42:46 2008 From: ww at styx.org (William Waites) Date: Mon, 1 Sep 2008 12:42:46 +0200 Subject: GLBX De-Peers Intercage In-Reply-To: References: <20080901.014812.9559.0@webmail03.vgs.untd.com> <776398FC-BFA7-4555-B2E0-36E03BC7D714@styx.org> <20080901101825.GH19179@skywalker.creative.net.au> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 08-09-01 ? 12:34, Gadi Evron a ?crit : >> Workeable suggestions? So far I've seen, >> >> * organized shunning >> * BGP blacklists > > I can see the "don't be the Internet's firewall" bunch jumping up > and out of their seats, spilling their coffees. How dare you destroy > so many keyboards? I didn't mean to imply that either of those was actually workeable ;) - -w - -- William Waites http://www.irl.styx.org/ +49 30 8894 9942 CD70 0498 8AE4 36EA 1CD7 281C 427A 3F36 2130 E9F5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAki7xyYACgkQQno/NiEw6fVbjACgx+BrvXakg1X5e2DEzJ2feqdi KGcAn1a7R2CrEmvw755UVRv0lhztz8tU =Ibnk -----END PGP SIGNATURE----- From deleskie at gmail.com Mon Sep 1 07:47:32 2008 From: deleskie at gmail.com (jim deleskie) Date: Mon, 1 Sep 2008 09:47:32 -0300 Subject: Force10 Gear - Opinions In-Reply-To: References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <48B41978.9040201@sprunk.org> Message-ID: The S series runs the same FTOS as the C and E series, as of a number of months ago. The only exception is the 2410, ie all 10G ports L2 only. -jim On Mon, Sep 1, 2008 at 3:19 AM, Greg VILLAIN wrote: > > On Aug 26, 2008, at 6:46 PM, Owen DeLong wrote: >> >> Another thing to note (as near as I can tell, this applies to all >> vendors). All line cards will function >> only at the lowest common denominator line card CAM level. >> >> IOW, if you have single, dual, and quad-cam cards in your F10 chassis, >> they'll all act like >> single-CAM cards. >> >> Owen > > > I'd have to second that. This is a very annoying fact, that you will find > mentioned nowhere. > What I also used to dislike is the lack of verbosity of 'show features' - > but that was back a year ago. > Btw, you absolutely want to avoid the S series, the CLI is a pain, and is > not the same as the E or C series, and lacks many features. > Price/10G port is interesting though, but not as much as with Arastra, if > that's switching you're into. (never tested any such kits though...) > My own 2 cents. > > Greg VILLAIN > > > From LarrySheldon at cox.net Mon Sep 1 09:21:24 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Mon, 01 Sep 2008 09:21:24 -0500 Subject: GLBX De-Peers Intercage [Was: RE: Washington Post: Atrivo/Intercag e, w hy are we peering with the American RBN?] In-Reply-To: <7679.1220261807@turing-police.cc.vt.edu> References: <20080901.014812.9559.0@webmail03.vgs.untd.com> <7679.1220261807@turing-police.cc.vt.edu> Message-ID: <48BBFA64.8020100@cox.net> Valdis.Kletnieks at vt.edu wrote: > On Mon, 01 Sep 2008 08:48:12 -0000, Paul Ferguson said: >> Is this an issue that network operations folk don't really care >> about? > > If somebody's paying you $n/megabyte for transit/connectivity, what's your > incentive to make them clean up their act and get rid of their P2P filesharing > traffic, spam traffic, and so on? What is your price for cocaine? From Valdis.Kletnieks at vt.edu Mon Sep 1 10:08:20 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 01 Sep 2008 11:08:20 -0400 Subject: GLBX De-Peers Intercage [Was: RE: Washington Post: Atrivo/Intercag e, w hy are we peering with the American RBN?] In-Reply-To: Your message of "Mon, 01 Sep 2008 09:21:24 CDT." <48BBFA64.8020100@cox.net> References: <20080901.014812.9559.0@webmail03.vgs.untd.com> <7679.1220261807@turing-police.cc.vt.edu> <48BBFA64.8020100@cox.net> Message-ID: <17826.1220281700@turing-police.cc.vt.edu> On Mon, 01 Sep 2008 09:21:24 CDT, "Laurence F. Sheldon, Jr." said: > Valdis.Kletnieks at vt.edu wrote: > > On Mon, 01 Sep 2008 08:48:12 -0000, Paul Ferguson said: > > >> Is this an issue that network operations folk don't really care > >> about? > > > > If somebody's paying you $n/megabyte for transit/connectivity, what's your > > incentive to make them clean up their act and get rid of their P2P filesharing > > traffic, spam traffic, and so on? > > What is your price for cocaine? No, seriously.. If, as some estimates have it, 80% of the traffic is P2P, and as other estimates have it, 90% of that is copyright-infringing, then if that traffic disappears, anybody who was selling transit for that traffic is going to take a *big* revenue hit. And similarly, if you're selling transit to somebody who's then (eventually) reselling a pipe to Atrivio/Intercage or the RBN, turning that somebody off because they won't turn off the bad guys is going to make a dent in the bottom line. I think it's very disingenuous to pretend that there have been *no* providers that haven't said to themselves "We're selling to scum, but it pays the bills, and we'd be in bankruptcy court otherwise..." The fact that bad guys don't seem to have *any* trouble getting connectivity once they finally *do* get kicked off a provider is proof enough that: a) There exist providers that are willing to take money from scum. b) We won't get rid of the scum until we admit (a) is true. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From smb at cs.columbia.edu Mon Sep 1 10:33:21 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Mon, 1 Sep 2008 11:33:21 -0400 Subject: GLBX De-Peers Intercage [Was: RE: Washington Post: Atrivo/Intercag e, w hy are we peering with the American RBN?] In-Reply-To: <17826.1220281700@turing-police.cc.vt.edu> References: <20080901.014812.9559.0@webmail03.vgs.untd.com> <7679.1220261807@turing-police.cc.vt.edu> <48BBFA64.8020100@cox.net> <17826.1220281700@turing-police.cc.vt.edu> Message-ID: <20080901113321.666cf7aa@cs.columbia.edu> On Mon, 01 Sep 2008 11:08:20 -0400 Valdis.Kletnieks at vt.edu wrote: > a) There exist providers that are willing to take money from scum. > b) We won't get rid of the scum until we admit (a) is true. I mostly agree with you -- but I get very worried about who defines "scum". Consider the following cases, which I will assert are not very far-fetched: (a) China labels Falun Gong as "scum" and demands that international ISPs not carry it if they want to do business in China (b) Russia labels critics of Putin and Medvedev as "scum" and demands that international ISPs bar their traffic if they want to do business in Russia (c) Saudi Arabia denounces Internet pornographers as "scum" and demands that ISPs bar their traffic if they want their countries to be able to purchase oil (c) France and Germany label EBay as "scum" for not barring sales of Nazi memorabilia and demands that international ISPs not carry it if they want to do business in the EU (d) The RIAA and MPAA label file-sharers as "scum" and deny combined TV/ISP companies (cable ISPs, Verizon FIOS, etc.) access to any *broadcast* content if the ISP side doesn't crack down on file-sharing. These are slightly far-fetched, but only slightly. I have a nice real-world example that I need to verify is public first, but it's directly on this point. --Steve Bellovin, http://www.cs.columbia.edu/~smb From LarrySheldon at cox.net Mon Sep 1 10:43:29 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Mon, 01 Sep 2008 10:43:29 -0500 Subject: GLBX De-Peers Intercage [Was: RE: Washington Post: Atrivo/Intercag e, w hy are we peering with the American RBN?] In-Reply-To: <20080901113321.666cf7aa@cs.columbia.edu> References: <20080901.014812.9559.0@webmail03.vgs.untd.com> <7679.1220261807@turing-police.cc.vt.edu> <48BBFA64.8020100@cox.net> <17826.1220281700@turing-police.cc.vt.edu> <20080901113321.666cf7aa@cs.columbia.edu> Message-ID: <48BC0DA1.2040106@cox.net> Steven M. Bellovin wrote: > On Mon, 01 Sep 2008 11:08:20 -0400 > Valdis.Kletnieks at vt.edu wrote: > >> a) There exist providers that are willing to take money from scum. >> b) We won't get rid of the scum until we admit (a) is true. > > I mostly agree with you -- but I get very worried about who defines > "scum". Who defines "scum" when you get the email announcing a solution to your most urgent sexual problems? Who defines "scum" when the guy shows up at your office with a lot of the world's finest wrist watches for sale at unbelievably low prices? Who defines "scum" when you get the pallet of toner nobody remembers ordering? Who defines "scum" when the seedy character you never met before shows up to take your daughter out? From owen at delong.com Mon Sep 1 11:20:22 2008 From: owen at delong.com (Owen DeLong) Date: Mon, 1 Sep 2008 09:20:22 -0700 Subject: Force10 Gear - Opinions In-Reply-To: References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <48B41978.9040201@sprunk.org> Message-ID: Sort of... There are still some notable differences in behavior. Owen On Sep 1, 2008, at 5:47 AM, jim deleskie wrote: > The S series runs the same FTOS as the C and E series, as of a number > of months ago. The only exception is the 2410, ie all 10G ports L2 > only. > > > -jim > > On Mon, Sep 1, 2008 at 3:19 AM, Greg VILLAIN > wrote: >> >> On Aug 26, 2008, at 6:46 PM, Owen DeLong wrote: >>> >>> Another thing to note (as near as I can tell, this applies to all >>> vendors). All line cards will function >>> only at the lowest common denominator line card CAM level. >>> >>> IOW, if you have single, dual, and quad-cam cards in your F10 >>> chassis, >>> they'll all act like >>> single-CAM cards. >>> >>> Owen >> >> >> I'd have to second that. This is a very annoying fact, that you >> will find >> mentioned nowhere. >> What I also used to dislike is the lack of verbosity of 'show >> features' - >> but that was back a year ago. >> Btw, you absolutely want to avoid the S series, the CLI is a pain, >> and is >> not the same as the E or C series, and lacks many features. >> Price/10G port is interesting though, but not as much as with >> Arastra, if >> that's switching you're into. (never tested any such kits though...) >> My own 2 cents. >> >> Greg VILLAIN >> >> >> From Valdis.Kletnieks at vt.edu Mon Sep 1 11:32:46 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 01 Sep 2008 12:32:46 -0400 Subject: GLBX De-Peers Intercage [Was: RE: Washington Post: Atrivo/Intercag e, w hy are we peering with the American RBN?] In-Reply-To: Your message of "Mon, 01 Sep 2008 11:33:21 EDT." <20080901113321.666cf7aa@cs.columbia.edu> References: <20080901.014812.9559.0@webmail03.vgs.untd.com> <7679.1220261807@turing-police.cc.vt.edu> <48BBFA64.8020100@cox.net> <17826.1220281700@turing-police.cc.vt.edu> <20080901113321.666cf7aa@cs.columbia.edu> Message-ID: <26754.1220286766@turing-police.cc.vt.edu> On Mon, 01 Sep 2008 11:33:21 EDT, "Steven M. Bellovin" said: > On Mon, 01 Sep 2008 11:08:20 -0400 > Valdis.Kletnieks at vt.edu wrote: > > > a) There exist providers that are willing to take money from scum. > > b) We won't get rid of the scum until we admit (a) is true. > > I mostly agree with you -- but I get very worried about who defines > "scum". Consider the following cases, which I will assert are not very > far-fetched: For the sake of discussion, I was calling "scum" "any entity that your morals say you shouldn't accept money from, but your accountant says you should".... What that makes your accountant... is another discussion entirely :) However, I *do* agree with the problem of "scum with politico-economic leverage".... -------------- 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 Mon Sep 1 12:15:08 2008 From: vixie at isc.org (Paul Vixie) Date: Mon, 01 Sep 2008 17:15:08 +0000 Subject: GLBX De-Peers Intercage [Was: RE: Washington Post: Atrivo/Intercag In-Reply-To: <20080901.014812.9559.0@webmail03.vgs.untd.com> (Paul Ferguson's message of "Mon\, 1 Sep 2008 08\:48\:12 GMT") References: <20080901.014812.9559.0@webmail03.vgs.untd.com> Message-ID: fergdawg at netzero.net ("Paul Ferguson") writes: > My next question to the peanut gallery is: What do you suggest we should > do on other hosting IP blocks are are continuing to host criminal > activity, even in the face of abuse reports, etc.? depending on what you mean by "we", the immortal words of many MAPS lawsuits spring to mind here: "illegal conspiracy" and "prospective economic advantage." simply put, if a bunch of like-minded folks want to get together and decide that a given ISP is behaving badly and all decide to deny peering and transit to that ISP, then you should all first divorce your husband or wife after putting all joint assets in his or her name. > Seriously -- I think this is an issue which needs to be addressed > here. ISPs cannot continue to sweep this issue under the proverbial > carpet. > > Is this an issue that network operations folk don't really care about? the great unsolved problem in every network is "other people's networks". whether that's networks who won't peer with you, or networks who drop your customers' packets either because of shaping or overcommit, or networks who sell service to people you hate and then run a crappy abuse desk, it's all one thing: OPN: Other People's Networks. OPN's are an unmanageable risk to all of us. netops people generally sweep OPNs under the rug, yes. -- Paul Vixie From frnkblk at iname.com Mon Sep 1 14:36:04 2008 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 1 Sep 2008 14:36:04 -0500 Subject: GLBX De-Peers Intercage [Was: RE: Washington Post: Atrivo/Intercag In-Reply-To: References: <20080901.014812.9559.0@webmail03.vgs.untd.com> Message-ID: Any discussion on this or any other public list about joint action could be portrayed as conspiracy. As Paul said, set your financial and carreer affairs in order before doing so. Better for each company's netops to quietly blacklist IPs/netblocks/ASNs as they each see fit. If the traffic coming/going to there is truly garbage, then customers won't complain. If there are valid concerns, then operators can work with their customers individiually. Frank -----Original Message----- From: Paul Vixie [mailto:vixie at isc.org] Sent: Monday, September 01, 2008 12:15 PM To: nanog at merit.edu Subject: Re: GLBX De-Peers Intercage [Was: RE: Washington Post: Atrivo/Intercag fergdawg at netzero.net ("Paul Ferguson") writes: > My next question to the peanut gallery is: What do you suggest we should > do on other hosting IP blocks are are continuing to host criminal > activity, even in the face of abuse reports, etc.? depending on what you mean by "we", the immortal words of many MAPS lawsuits spring to mind here: "illegal conspiracy" and "prospective economic advantage." simply put, if a bunch of like-minded folks want to get together and decide that a given ISP is behaving badly and all decide to deny peering and transit to that ISP, then you should all first divorce your husband or wife after putting all joint assets in his or her name. > Seriously -- I think this is an issue which needs to be addressed > here. ISPs cannot continue to sweep this issue under the proverbial > carpet. > > Is this an issue that network operations folk don't really care about? the great unsolved problem in every network is "other people's networks". whether that's networks who won't peer with you, or networks who drop your customers' packets either because of shaping or overcommit, or networks who sell service to people you hate and then run a crappy abuse desk, it's all one thing: OPN: Other People's Networks. OPN's are an unmanageable risk to all of us. netops people generally sweep OPNs under the rug, yes. -- Paul Vixie From emoazzam at gmail.com Mon Sep 1 14:37:19 2008 From: emoazzam at gmail.com (Moazzam Khan) Date: Mon, 1 Sep 2008 15:37:19 -0400 Subject: BGP Scalability Simulation Message-ID: <174dd5570809011237w2a3fa4d3j661f39a60ca9ffaa@mail.gmail.com> Hi I am trying to simulate BGP for scalability testing. I have few queries. 1) What sort of topology I should try out ? 2) What parameters should I test? I am trying to simulate it in ns-2 and i would appreciate reply from you guys. Regards MAK From howard at leadmon.net Mon Sep 1 14:42:10 2008 From: howard at leadmon.net (Howard Leadmon) Date: Mon, 1 Sep 2008 15:42:10 -0400 Subject: Washington Post: Atrivo/Intercage, why are we peering with the American RBN? In-Reply-To: References: Message-ID: <011301c90c6a$d6382440$82a86cc0$@net> Guess I need to look in more detail, but doesn't looking at that show that CHINANET has about half the rouge network infections of the overall network. Sounds like if you don't do business with China, putting in a blackhole on AS4134 (and maybe 4837 and 4812) would knock out the majority of the trouble sites. Heck, and maybe I am in the dark ages, I didn't realize google was providing that much connectivity, why the heck do they have so many infected machines. Unless I am just reading that stuff wrong, guess I need to take my time and go through it. I am not in the wholesale bandwidth game anymore, but I have sure suffered my share of DDoS attacks, and am all for any intelligent things I can do to help eliminate such future issues.. --- Howard Leadmon > -----Original Message----- > From: Suresh Ramasubramanian [mailto:ops.lists at gmail.com] > Sent: Friday, August 29, 2008 4:38 PM > To: Gadi Evron > Cc: nanog at merit.edu > Subject: Re: Washington Post: Atrivo/Intercage, why are we peering with > the American RBN? > > On Sat, Aug 30, 2008 at 1:32 AM, Gadi Evron wrote: > > 2. On a different note, why is anyone still accepting their route > > announcements? I know some among us re-route RBN traffic to protect > users. > > Do you see this as a valid solution for your networks? > > > > What ASNs belong to Atrivo, anyway? > > The ASNs you ask about - as per the report - are on pages 4..8 of > http://hostexploit.com/downloads/Atrivo%20white%20paper%20082808ac.pdf From fergdawg at netzero.net Mon Sep 1 14:43:51 2008 From: fergdawg at netzero.net (Paul Ferguson) Date: Mon, 1 Sep 2008 19:43:51 GMT Subject: GLBX De-Peers Intercage [Was: RE: Washington Post: Atrivo/Intercag e, why are we peering with the American RBN?] Message-ID: <20080901.124351.3465.4@webmail04.vgs.untd.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- "Steven M. Bellovin" wrote: >On Mon, 01 Sep 2008 11:08:20 -0400 Valdis.Kletnieks at vt.edu wrote: > >> a) There exist providers that are willing to take money from scum. >> b) We won't get rid of the scum until we admit (a) is true. > >I mostly agree with you -- but I get very worried about who defines >"scum". Consider the following cases, which I will assert are not very >far-fetched: > I can certainly see how the definition of "scum" could be hijacked to fit any particular political agenda, too. For the particular purposes I referred to earlier, the definition would be: "Continuing to allow criminal activity to occur within your network." "Criminal activity" is easily definable by laws which state that malicious, willful, and concerted attempts to perpetrate financial theft, fraud, and unauthorized computer tampering are illegal. But with all the ensuing discussion, it would appear that this is a matter in which ISPs defer, and a matter best addressed by law enforcement. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFIvEXpq1pz9mNUZTMRAhRNAJ9nzEVp3PCAoQKFKltQFRwh3yLpwACg0gRO EnWO3Y4YQ/Z+F52z5il6Pdg= =cMVa -----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 Stefan.Fouant at neustar.biz Mon Sep 1 14:51:56 2008 From: Stefan.Fouant at neustar.biz (Fouant, Stefan) Date: Mon, 1 Sep 2008 15:51:56 -0400 Subject: BGP Scalability Simulation Message-ID: Topology and setup of these kinds of tests largely depend on whether you are testing iBGP or eBGP. In my experience, eBGP testing is fairly straight forward as you are almost always testing reconvergence of the BGP next-hop. iBGP testing scenarios on the other hand can be quite a bit more complex as you may also be testing the reconvergence of the underlying IGP if the BGP next-hop remains unchanged. Can you describe your testing goals and environment in a bit more detail? Stefan Fouant Principal Network Engineer NeuStar, Inc. - http://www.neustar.biz GPG Key ID: 0xB5E3803D ----- Original Message ----- From: Moazzam Khan To: nanog at nanog.org Sent: Mon Sep 01 15:37:19 2008 Subject: BGP Scalability Simulation Hi I am trying to simulate BGP for scalability testing. I have few queries. 1) What sort of topology I should try out ? 2) What parameters should I test? I am trying to simulate it in ns-2 and i would appreciate reply from you guys. Regards MAK From emoazzam at gmail.com Mon Sep 1 14:57:46 2008 From: emoazzam at gmail.com (Moazzam Khan) Date: Mon, 1 Sep 2008 15:57:46 -0400 Subject: BGP Scalability Simulation In-Reply-To: References: Message-ID: <174dd5570809011257i20f0dedct8aa598daf6505ff0@mail.gmail.com> Thanks Stefan for your reply. Basically the goal of this testing is to study the BGP scalability issues in the internet sometime in future lets say 10 years from now and try to find out what problems it could face . I am trying to use ns2 as my simulation environment. Can you suggest how I can set up the envrionment for this kind of study and what parameters should I try to caputre. Regards MAK On Mon, Sep 1, 2008 at 3:51 PM, Fouant, Stefan wrote: > Topology and setup of these kinds of tests largely depend on whether you > are testing iBGP or eBGP. In my experience, eBGP testing is fairly straight > forward as you are almost always testing reconvergence of the BGP next-hop. > iBGP testing scenarios on the other hand can be quite a bit more complex as > you may also be testing the reconvergence of the underlying IGP if the BGP > next-hop remains unchanged. Can you describe your testing goals and > environment in a bit more detail? > > Stefan Fouant > Principal Network Engineer > NeuStar, Inc. - http://www.neustar.biz > GPG Key ID: 0xB5E3803D > > > ----- Original Message ----- > From: Moazzam Khan > To: nanog at nanog.org > Sent: Mon Sep 01 15:37:19 2008 > Subject: BGP Scalability Simulation > > Hi > > I am trying to simulate BGP for scalability testing. I have few queries. > > > 1) What sort of topology I should try out ? > > 2) What parameters should I test? > > I am trying to simulate it in ns-2 and i would appreciate reply from you > guys. > > Regards > > MAK > From robert at tellurian.com Mon Sep 1 19:50:46 2008 From: robert at tellurian.com (Robert Boyle) Date: Mon, 01 Sep 2008 20:50:46 -0400 Subject: 10GE CWDM In-Reply-To: <53A6C7E936ED8544B1A2BC990D254F942EA6F7697F@MEMEXG1.HOST.lo cal> References: <922203.27764.qm@web65506.mail.ac4.yahoo.com> <53A6C7E936ED8544B1A2BC990D254F942EA6F7697F@MEMEXG1.HOST.local> Message-ID: <1220316646_267033@mail1.tellurian.net> At 12:03 AM 8/31/2008, you wrote: >Currently it is my understanding the 10 Gbps signals are carried on >4 x 2.5 Gbps signals that are compatible with existing CWDM and DWDM >equipment. There are 40 Gbps DWDM systems and 10 Gbps lasers on 100 >Gbps and greater capacity systems. I agree with Alex's comments that >to have 10 Gbps on a CWDM system is to have a CWDM system of at >least 40 to 100 Gbps and that is very expensive today. The only affordable CWDM 10G system I have seen although I haven't used it yet is a single 10G band at 1310 or 1550 with 8 additional 2.5G bands around it. I haven't seen any 4 band 10G CWDM boxes with XFPs for less than $5000 yet, but I would expect them in the next year or two - I'm hoping anyway. I'm out of the country at the moment and access is a bit too slow to look it up easily now. If you need the manufacturer, let me know and I'll look it up when I return. -Robert Tellurian Networks - Global Hosting Solutions Since 1995 http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "Well done is better than well said." - Benjamin Franklin From rgolodner at infratection.com Tue Sep 2 00:11:03 2008 From: rgolodner at infratection.com (Richard Golodner) Date: Tue, 2 Sep 2008 00:11:03 -0500 Subject: GLBX De-Peers Intercage [Was: RE: Washington Post: Atrivo/Intercag In-Reply-To: References: <20080901.014812.9559.0@webmail03.vgs.untd.com> Message-ID: <6AC89D827FD940E8A44A08897DF631A6@Antares> Paul Vixie said on 9/1/08 "OPN's are an unmanageable risk to all of us. Netops people generally sweep OPNs under the rug, yes." I agree completely, but how do we begin to address this problem? Words are not enough, we need some action and that action, whatever it may be will make the public network a better place for all of us. Divorcing my wife after 6 hours in the car with a newborn and a 4 day visit with my in-laws has a very real appeal to it. Hmmm... most sincerely, Richard Golodner From alex at pilosoft.com Tue Sep 2 00:21:03 2008 From: alex at pilosoft.com (Alex Pilosov) Date: Tue, 2 Sep 2008 01:21:03 -0400 (EDT) Subject: 10GE CWDM In-Reply-To: <1220316646_267033@mail1.tellurian.net> Message-ID: On Mon, 1 Sep 2008, Robert Boyle wrote: > At 12:03 AM 8/31/2008, you wrote: > >Currently it is my understanding the 10 Gbps signals are carried on > >4 x 2.5 Gbps signals that are compatible with existing CWDM and DWDM > >equipment. There are 40 Gbps DWDM systems and 10 Gbps lasers on 100 > >Gbps and greater capacity systems. I agree with Alex's comments that > >to have 10 Gbps on a CWDM system is to have a CWDM system of at > >least 40 to 100 Gbps and that is very expensive today. > > The only affordable CWDM 10G system I have seen although I haven't used > it yet is a single 10G band at 1310 or 1550 with 8 additional 2.5G bands > around it. I haven't seen any 4 band 10G CWDM boxes with XFPs for less > than $5000 yet, but I would expect them in the next year or two - I'm > hoping anyway. I'm out of the country at the moment and access is a bit > too slow to look it up easily now. If you need the manufacturer, let me > know and I'll look it up when I return. Depending how cheap and ghetto you want to get, there's also possibility of doing WDM on 1310/1300. I have custom-manufactured splitters filtering 1307nm +-2nm - and any given LR XFP [*1] will be either within that band or outside [*2]. Test a bunch of them, split them into two groups, use on the "tested" wavelength. Bunch of friends&family are using this technology in production. This gives you an ability to do 20G with very cheap optics. [*1] Except ones with very temperature dependent wavelength - mark them as "warms up to 1300" and use if you don't care that your links will take about 5 minutes to "warm up" and come up. :) [*2] Any LX4 Xenpak would be "outside" of the band as well, and you can use LX4 concurrently with LR. There are some more ghetto fabulous things you can do, described in http://www.nanog.org/mtg-0610/presenter-pdfs/pilosov.pdf ;) -alex From Olivier.Bonaventure at uclouvain.be Tue Sep 2 02:31:42 2008 From: Olivier.Bonaventure at uclouvain.be (Olivier Bonaventure) Date: Tue, 02 Sep 2008 09:31:42 +0200 Subject: BGP Scalability Simulation In-Reply-To: <174dd5570809011237w2a3fa4d3j661f39a60ca9ffaa@mail.gmail.com> References: <174dd5570809011237w2a3fa4d3j661f39a60ca9ffaa@mail.gmail.com> Message-ID: <48BCEBDE.5090807@uclouvain.be> Moazzam, > > I am trying to simulate BGP for scalability testing. I have few queries. > > > 1) What sort of topology I should try out ? You might have a look at igen and cbgp available from http://inl.info.ucl.ac.be/softwares Olivier From bradfreeman at gmail.com Tue Sep 2 07:41:22 2008 From: bradfreeman at gmail.com (Brad Freeman) Date: Tue, 2 Sep 2008 15:41:22 +0300 Subject: BGP Scalability Simulation In-Reply-To: <174dd5570809011257i20f0dedct8aa598daf6505ff0@mail.gmail.com> References: <174dd5570809011257i20f0dedct8aa598daf6505ff0@mail.gmail.com> Message-ID: <17473cc0809020541v7b4dd5fcs466efbd5f041ac19@mail.gmail.com> Vince Fuller has done some projections on what the the routing tables will be like in the near future which would be useful for you, check out http://www.ripe.net/ripe/meetings/ripe-53/presentations/rou-vf-sca.pdf If you are looking at doing simulations of what it could be like, use similar figures to his for IPv4 & IPv6 routing table size. Regards Bradley Freeman 2008/9/1 Moazzam Khan > Thanks Stefan for your reply. > > Basically the goal of this testing is to study the BGP scalability issues > in > the internet sometime in future lets say 10 years from now and try to find > out what problems it could face . I am trying to use ns2 as my simulation > environment. > > Can you suggest how I can set up the envrionment for this kind of study and > what parameters should I try to caputre. > > Regards > MAK > > On Mon, Sep 1, 2008 at 3:51 PM, Fouant, Stefan >wrote: > > > Topology and setup of these kinds of tests largely depend on whether you > > are testing iBGP or eBGP. In my experience, eBGP testing is fairly > straight > > forward as you are almost always testing reconvergence of the BGP > next-hop. > > iBGP testing scenarios on the other hand can be quite a bit more complex > as > > you may also be testing the reconvergence of the underlying IGP if the > BGP > > next-hop remains unchanged. Can you describe your testing goals and > > environment in a bit more detail? > > > > Stefan Fouant > > Principal Network Engineer > > NeuStar, Inc. - http://www.neustar.biz > > GPG Key ID: 0xB5E3803D > > > > > > ----- Original Message ----- > > From: Moazzam Khan > > To: nanog at nanog.org > > Sent: Mon Sep 01 15:37:19 2008 > > Subject: BGP Scalability Simulation > > > > Hi > > > > I am trying to simulate BGP for scalability testing. I have few queries. > > > > > > 1) What sort of topology I should try out ? > > > > 2) What parameters should I test? > > > > I am trying to simulate it in ns-2 and i would appreciate reply from you > > guys. > > > > Regards > > > > MAK > > > From dga at cs.cmu.edu Tue Sep 2 09:48:14 2008 From: dga at cs.cmu.edu (David Andersen) Date: Tue, 2 Sep 2008 10:48:14 -0400 Subject: BGP Scalability Simulation In-Reply-To: <17473cc0809020541v7b4dd5fcs466efbd5f041ac19@mail.gmail.com> References: <174dd5570809011257i20f0dedct8aa598daf6505ff0@mail.gmail.com> <17473cc0809020541v7b4dd5fcs466efbd5f041ac19@mail.gmail.com> Message-ID: <9B5D7E51-0D6B-4D62-8A0B-66D2BA71F069@cs.cmu.edu> We have a similar analysis (which agrees with Vince Fuller's #s in a general sense) in the middle of a recent sigcomm paper: http://www.aip-arch.net/ See the paper "Accountable Internet Protocol (AIP)". I point it out mostly because the Fuller presentation said "kinda looks exponential"; we found that the scaling was 17% per year, which could be a bit more useful if you need to come up with #s for the years between when Fuller provides projections for. -Dave On Sep 2, 2008, at 8:41 AM, Brad Freeman wrote: > Vince Fuller has done some projections on what the the routing > tables will > be like in the near future which would be useful for you, check out > http://www.ripe.net/ripe/meetings/ripe-53/presentations/rou-vf-sca.pdf > > If you are looking at doing simulations of what it could be like, use > similar figures to his for IPv4 & IPv6 routing table size. > > Regards > > Bradley Freeman > > 2008/9/1 Moazzam Khan > >> Thanks Stefan for your reply. >> >> Basically the goal of this testing is to study the BGP scalability >> issues >> in >> the internet sometime in future lets say 10 years from now and try >> to find >> out what problems it could face . I am trying to use ns2 as my >> simulation >> environment. >> >> Can you suggest how I can set up the envrionment for this kind of >> study and >> what parameters should I try to caputre. >> >> Regards >> MAK >> >> On Mon, Sep 1, 2008 at 3:51 PM, Fouant, Stefan >> wrote: >> >>> Topology and setup of these kinds of tests largely depend on >>> whether you >>> are testing iBGP or eBGP. In my experience, eBGP testing is fairly >> straight >>> forward as you are almost always testing reconvergence of the BGP >> next-hop. >>> iBGP testing scenarios on the other hand can be quite a bit more >>> complex >> as >>> you may also be testing the reconvergence of the underlying IGP if >>> the >> BGP >>> next-hop remains unchanged. Can you describe your testing goals and >>> environment in a bit more detail? >>> >>> Stefan Fouant >>> Principal Network Engineer >>> NeuStar, Inc. - http://www.neustar.biz >>> GPG Key ID: 0xB5E3803D >>> >>> >>> ----- Original Message ----- >>> From: Moazzam Khan >>> To: nanog at nanog.org >>> Sent: Mon Sep 01 15:37:19 2008 >>> Subject: BGP Scalability Simulation >>> >>> Hi >>> >>> I am trying to simulate BGP for scalability testing. I have few >>> queries. >>> >>> >>> 1) What sort of topology I should try out ? >>> >>> 2) What parameters should I test? >>> >>> I am trying to simulate it in ns-2 and i would appreciate reply >>> from you >>> guys. >>> >>> Regards >>> >>> MAK >>> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From mksmith at adhost.com Tue Sep 2 10:10:55 2008 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Tue, 2 Sep 2008 08:10:55 -0700 Subject: 10GE CWDM In-Reply-To: References: <1220316646_267033@mail1.tellurian.net> Message-ID: <17838240D9A5544AAA5FF95F8D52031604903868@ad-exh01.adhost.lan> Hello Alex: > Depending how cheap and ghetto you want to get, there's also possibility > of doing WDM on 1310/1300. I have custom-manufactured splitters filtering > 1307nm +-2nm - and any given LR XFP [*1] will be either within that band > or outside [*2]. Test a bunch of them, split them into two groups, use on > the "tested" wavelength. Bunch of friends&family are using this technology > in production. This gives you an ability to do 20G with very cheap optics. > > > [*1] Except ones with very temperature dependent wavelength - mark them as > "warms up to 1300" and use if you don't care that your links will take > about 5 minutes to "warm up" and come up. :) > > [*2] Any LX4 Xenpak would be "outside" of the band as well, and you can > use LX4 concurrently with LR. > > There are some more ghetto fabulous things you can do, described in > http://www.nanog.org/mtg-0610/presenter-pdfs/pilosov.pdf ;) > > -alex > Do you have any issues with four wave mixing or other crosstalk issues or do you account for this in your channel plan? Regards, Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 474 bytes Desc: not available URL: From rveloso at cs.ucla.edu Tue Sep 2 12:35:28 2008 From: rveloso at cs.ucla.edu (Ricardo Oliveira) Date: Tue, 2 Sep 2008 10:35:28 -0700 Subject: BGP Scalability Simulation In-Reply-To: <174dd5570809011257i20f0dedct8aa598daf6505ff0@mail.gmail.com> References: <174dd5570809011257i20f0dedct8aa598daf6505ff0@mail.gmail.com> Message-ID: Moazzam, Do you have something specific in mind you want to measure? e.g. convergence times, table size, update count, etc? the scope of your study seems to broad as you describe it.. Cheers, --Ricardo On Sep 1, 2008, at 12:57 PM, Moazzam Khan wrote: > Thanks Stefan for your reply. > > Basically the goal of this testing is to study the BGP scalability > issues in > the internet sometime in future lets say 10 years from now and try > to find > out what problems it could face . I am trying to use ns2 as my > simulation > environment. > > Can you suggest how I can set up the envrionment for this kind of > study and > what parameters should I try to caputre. > > Regards > MAK > > On Mon, Sep 1, 2008 at 3:51 PM, Fouant, Stefan > wrote: > >> Topology and setup of these kinds of tests largely depend on >> whether you >> are testing iBGP or eBGP. In my experience, eBGP testing is fairly >> straight >> forward as you are almost always testing reconvergence of the BGP >> next-hop. >> iBGP testing scenarios on the other hand can be quite a bit more >> complex as >> you may also be testing the reconvergence of the underlying IGP if >> the BGP >> next-hop remains unchanged. Can you describe your testing goals and >> environment in a bit more detail? >> >> Stefan Fouant >> Principal Network Engineer >> NeuStar, Inc. - http://www.neustar.biz >> GPG Key ID: 0xB5E3803D >> >> >> ----- Original Message ----- >> From: Moazzam Khan >> To: nanog at nanog.org >> Sent: Mon Sep 01 15:37:19 2008 >> Subject: BGP Scalability Simulation >> >> Hi >> >> I am trying to simulate BGP for scalability testing. I have few >> queries. >> >> >> 1) What sort of topology I should try out ? >> >> 2) What parameters should I test? >> >> I am trying to simulate it in ns-2 and i would appreciate reply >> from you >> guys. >> >> Regards >> >> MAK >> From emoazzam at gmail.com Tue Sep 2 12:43:28 2008 From: emoazzam at gmail.com (Moazzam Khan) Date: Tue, 2 Sep 2008 13:43:28 -0400 Subject: BGP Scalability Simulation In-Reply-To: References: <174dd5570809011257i20f0dedct8aa598daf6505ff0@mail.gmail.com> Message-ID: <174dd5570809021043o4d8f5322x86bb5b60bba9918e@mail.gmail.com> Hi Ricardo, Basically I want to measure the Convergence times and routing table sizes. But I am not able to find a good topology of internet which I can utilize for my experimentations. I am looking at GT-ITM, BRITE and IGen but don't know what kind of abstraction they provide and if these topologies are feasible to test the above mentioned parameters. What challenges I can face if I want to measure all those parameters convergence times ,table sizes , update count, signal sizes etc. Regards Moazzam On Tue, Sep 2, 2008 at 1:35 PM, Ricardo Oliveira wrote: > Moazzam, > > Do you have something specific in mind you want to measure? e.g. > convergence times, table size, update count, etc? the scope of your study > seems to broad as you describe it.. > Cheers, > > --Ricardo > > > On Sep 1, 2008, at 12:57 PM, Moazzam Khan wrote: > > Thanks Stefan for your reply. >> >> Basically the goal of this testing is to study the BGP scalability issues >> in >> the internet sometime in future lets say 10 years from now and try to find >> out what problems it could face . I am trying to use ns2 as my simulation >> environment. >> >> Can you suggest how I can set up the envrionment for this kind of study >> and >> what parameters should I try to caputre. >> >> Regards >> MAK >> >> On Mon, Sep 1, 2008 at 3:51 PM, Fouant, Stefan > >wrote: >> >> Topology and setup of these kinds of tests largely depend on whether you >>> are testing iBGP or eBGP. In my experience, eBGP testing is fairly >>> straight >>> forward as you are almost always testing reconvergence of the BGP >>> next-hop. >>> iBGP testing scenarios on the other hand can be quite a bit more complex >>> as >>> you may also be testing the reconvergence of the underlying IGP if the >>> BGP >>> next-hop remains unchanged. Can you describe your testing goals and >>> environment in a bit more detail? >>> >>> Stefan Fouant >>> Principal Network Engineer >>> NeuStar, Inc. - http://www.neustar.biz >>> GPG Key ID: 0xB5E3803D >>> >>> >>> ----- Original Message ----- >>> From: Moazzam Khan >>> To: nanog at nanog.org >>> Sent: Mon Sep 01 15:37:19 2008 >>> Subject: BGP Scalability Simulation >>> >>> Hi >>> >>> I am trying to simulate BGP for scalability testing. I have few queries. >>> >>> >>> 1) What sort of topology I should try out ? >>> >>> 2) What parameters should I test? >>> >>> I am trying to simulate it in ns-2 and i would appreciate reply from you >>> guys. >>> >>> Regards >>> >>> MAK >>> >>> > > From rveloso at CS.UCLA.EDU Tue Sep 2 13:04:49 2008 From: rveloso at CS.UCLA.EDU (Ricardo Oliveira) Date: Tue, 2 Sep 2008 11:04:49 -0700 Subject: BGP Scalability Simulation In-Reply-To: <174dd5570809021043o4d8f5322x86bb5b60bba9918e@mail.gmail.com> References: <174dd5570809011257i20f0dedct8aa598daf6505ff0@mail.gmail.com> <174dd5570809021043o4d8f5322x86bb5b60bba9918e@mail.gmail.com> Message-ID: The topos you mentioned are synthetic (e.g. generated based on math), you might want to check these ones instead, based on bgp tables from public sources: http://irl.cs.ucla.edu/topology/ Also, i don't think using a full internet topology is the way to go to do measure convergence time. The reason is that convergence time is highly dependent on ibgp architecture, router timers, etc and modeling things as one router per AS is at most unrealistic for this purpose. I would suggest to look at a small yet realistic topology of a few ISPs, e.g. as given by rocket fuel: http://www.cs.washington.edu/research/networking/rocketfuel/ For routing table size, you just need to grab the existing available routing tables, e.g. http://www.routeviews.org/ and do an extrapolation of the number of prefixes in RIB n years from now --Ricardo On Sep 2, 2008, at 10:43 AM, Moazzam Khan wrote: > Hi Ricardo, > > Basically I want to measure the Convergence times and routing table > sizes. But I am not able to find a good topology of internet which > I can utilize for my experimentations. I am looking at GT-ITM, > BRITE and IGen but don't know what kind of abstraction they provide > and if these topologies are feasible to test the above mentioned > parameters. > > What challenges I can face if I want to measure all those > parameters convergence times ,table sizes , update count, signal > sizes etc. > > > Regards > Moazzam > > On Tue, Sep 2, 2008 at 1:35 PM, Ricardo Oliveira > wrote: > Moazzam, > > Do you have something specific in mind you want to measure? e.g. > convergence times, table size, update count, etc? the scope of your > study seems to broad as you describe it.. > Cheers, > > --Ricardo > > > On Sep 1, 2008, at 12:57 PM, Moazzam Khan wrote: > > Thanks Stefan for your reply. > > Basically the goal of this testing is to study the BGP scalability > issues in > the internet sometime in future lets say 10 years from now and try > to find > out what problems it could face . I am trying to use ns2 as my > simulation > environment. > > Can you suggest how I can set up the envrionment for this kind of > study and > what parameters should I try to caputre. > > Regards > MAK > > On Mon, Sep 1, 2008 at 3:51 PM, Fouant, Stefan > wrote: > > Topology and setup of these kinds of tests largely depend on > whether you > are testing iBGP or eBGP. In my experience, eBGP testing is fairly > straight > forward as you are almost always testing reconvergence of the BGP > next-hop. > iBGP testing scenarios on the other hand can be quite a bit more > complex as > you may also be testing the reconvergence of the underlying IGP if > the BGP > next-hop remains unchanged. Can you describe your testing goals and > environment in a bit more detail? > > Stefan Fouant > Principal Network Engineer > NeuStar, Inc. - http://www.neustar.biz > GPG Key ID: 0xB5E3803D > > > ----- Original Message ----- > From: Moazzam Khan > To: nanog at nanog.org > Sent: Mon Sep 01 15:37:19 2008 > Subject: BGP Scalability Simulation > > Hi > > I am trying to simulate BGP for scalability testing. I have few > queries. > > > 1) What sort of topology I should try out ? > > 2) What parameters should I test? > > I am trying to simulate it in ns-2 and i would appreciate reply > from you > guys. > > Regards > > MAK > > > > From justin at justinshore.com Tue Sep 2 17:07:13 2008 From: justin at justinshore.com (Justin Shore) Date: Tue, 02 Sep 2008 17:07:13 -0500 Subject: GLBX De-Peers Intercage [Was: RE: Washington Post: Atrivo/Intercag e, w hy are we peering with the American RBN?] In-Reply-To: <20080901.014812.9559.0@webmail03.vgs.untd.com> References: <20080901.014812.9559.0@webmail03.vgs.untd.com> Message-ID: <48BDB911.6010404@justinshore.com> Paul Ferguson wrote: > My next question to the peanut gallery is: What do you > suggest we should do on other hosting IP blocks are are continuing > to host criminal activity, even in the face of abuse reports, etc.? > > Seriously -- I think this is an issue which needs to be addressed > here. ISPs cannot continue to sweep this issue under the proverbial > carpet. > > Is this an issue that network operations folk don't really care > about? IMHO policy should only be dictated by the edge, never upstream of that point. Now whether the edge is defined as the edge provider or the actual end-user is up for debate. I don't want my upstreams to make a decision what my SP and thus my customers can get to. My customers can't contact my upstream and argue for listing or delisting a given IP like they can with me. They can't speak with their dollars to my upstream like that can with me, their edge provider. Then again should I as the edge provider filter for my customers? Value-add service or a bonus service? It depends on your point of view. Justin From danm at prime.gushi.org Tue Sep 2 17:24:21 2008 From: danm at prime.gushi.org (Dan Mahoney, System Admin) Date: Tue, 2 Sep 2008 18:24:21 -0400 (EDT) Subject: 198.32.64.12 -- Harmless mis-route or potential exploit? Message-ID: Hello all, While recently trying to debug a CEF issue, I found a good number of packets in my "debug cef drops" output that were all directed at 198.32.64.12 (which I see as being allocated to ep.net but completely unused). Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route Now, as nearly as I can tell, this IP address has never been used for anything, but I see occasional references to it, such as here: http://www.honeynet.org/papers/forensics/exploit.html So the question is, should I just ignore this as a properly dropped packet due to "no route" (this provider is running defaultless, so unless such a route exists, it should be okay). On the other hand, one of the other packets I'm seeing specifically refers to a DNS exploit, so should I then dispatch to people to trace down the source origin ? (Suffice it to say the resources are there to find it fairly easily, even if the source address is forged). -Dan -- --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --------------------------- From ge at linuxbox.org Tue Sep 2 17:28:36 2008 From: ge at linuxbox.org (Gadi Evron) Date: Tue, 2 Sep 2008 17:28:36 -0500 (CDT) Subject: 198.32.64.12 -- Harmless mis-route or potential exploit? In-Reply-To: References: Message-ID: My profile and resume: http://www.linkedin.com/in/gadievron On Tue, 2 Sep 2008, Dan Mahoney, System Admin wrote: > Hello all, > > While recently trying to debug a CEF issue, I found a good number of packets > in my "debug cef drops" output that were all directed at 198.32.64.12 (which > I see as being allocated to ep.net but completely unused). > > Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route > Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route > Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route > Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route > Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route > Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route > Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route > Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route > > Now, as nearly as I can tell, this IP address has never been used for > anything, but I see occasional references to it, such as here: > > http://www.honeynet.org/papers/forensics/exploit.html > > So the question is, should I just ignore this as a properly dropped packet > due to "no route" (this provider is running defaultless, so unless such a > route exists, it should be okay). > > On the other hand, one of the other packets I'm seeing specifically refers to > a DNS exploit, so should I then dispatch to people to trace down the source > origin ? (Suffice it to say the resources are there to find it fairly > easily, even if the source address is forged). It should be treated as an intelligence source, sharing that one openly is probably counter-productive. Regardless, very interesting. I think follow-up just for interest's sake may be worth it. > -Dan > > -- > > --------Dan Mahoney-------- > Techie, Sysadmin, WebGeek > Gushi on efnet/undernet IRC > ICQ: 13735144 AIM: LarpGM > Site: http://www.gushi.org > --------------------------- > > From conte at isoc.org Tue Sep 2 17:33:42 2008 From: conte at isoc.org (Steve Conte) Date: Tue, 2 Sep 2008 15:33:42 -0700 Subject: 198.32.64.12 -- Harmless mis-route or potential exploit? In-Reply-To: References: Message-ID: <1E47901E-256B-4CAD-92DB-15493D6565FA@isoc.org> On Sep 2, 2008, at 3:24 PM, Dan Mahoney, System Admin wrote: > Hello all, > > While recently trying to debug a CEF issue, I found a good number of > packets in my "debug cef drops" output that were all directed at > 198.32.64.12 (which I see as being allocated to ep.net but > completely unused). > > Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route > Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route > Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route > Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route > Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route > Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route > Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route > Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route > > Now, as nearly as I can tell, this IP address has never been used > for anything, but I see occasional references to it, such as here: > Once upon a time, that used to be the IP address for the L Root server. Steve > ----- Steve Conte conte at isoc.org From pauldotwall at gmail.com Tue Sep 2 17:44:44 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Tue, 2 Sep 2008 18:44:44 -0400 Subject: 198.32.64.12 -- Harmless mis-route or potential exploit? In-Reply-To: References: Message-ID: <620fd17c0809021544j189cb77al36a34ba970bb6463@mail.gmail.com> Gadi, Could you please take the self-promotion offline already? Enough is enough! I don't think anybody on this list is interested in hiring you or reviewing your resume! (It could be argued that my post is off-topic as well. I disagree. Furthermore, it had to be done, given the lack of public face or consistent enforcement action of the current MLC.) Drive Slow, Paul Wall http://www.linkedin.com/in/paulwall On Tue, Sep 2, 2008 at 6:28 PM, Gadi Evron wrote: > My profile and resume: http://www.linkedin.com/in/gadievron > On Tue, 2 Sep 2008, Dan Mahoney, System Admin wrote: > >> Hello all, >> >> While recently trying to debug a CEF issue, I found a good number of >> packets in my "debug cef drops" output that were all directed at >> 198.32.64.12 (which I see as being allocated to ep.net but completely >> unused). >> >> Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route >> Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route >> Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route >> Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route >> Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route >> Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route >> Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route >> Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route >> >> Now, as nearly as I can tell, this IP address has never been used for >> anything, but I see occasional references to it, such as here: >> >> http://www.honeynet.org/papers/forensics/exploit.html >> >> So the question is, should I just ignore this as a properly dropped packet >> due to "no route" (this provider is running defaultless, so unless such a >> route exists, it should be okay). >> >> On the other hand, one of the other packets I'm seeing specifically refers >> to a DNS exploit, so should I then dispatch to people to trace down the >> source origin ? (Suffice it to say the resources are there to find it >> fairly easily, even if the source address is forged). > > It should be treated as an intelligence source, sharing that one openly is > probably counter-productive. > > Regardless, very interesting. I think follow-up just for interest's sake may > be worth it. > > >> -Dan >> >> -- >> >> --------Dan Mahoney-------- >> Techie, Sysadmin, WebGeek >> Gushi on efnet/undernet IRC >> ICQ: 13735144 AIM: LarpGM >> Site: http://www.gushi.org >> --------------------------- >> >> > > From drc at virtualized.org Tue Sep 2 18:31:40 2008 From: drc at virtualized.org (David Conrad) Date: Tue, 2 Sep 2008 16:31:40 -0700 Subject: 198.32.64.12 -- Harmless mis-route or potential exploit? In-Reply-To: References: Message-ID: <160A3E60-585D-4B34-88FE-8B09A8085893@virtualized.org> On Sep 2, 2008, at 3:24 PM, Dan Mahoney, System Admin wrote: > While recently trying to debug a CEF issue, I found a good number of > packets in my "debug cef drops" output that were all directed at > 198.32.64.12 (which I see as being allocated to ep.net but > completely unused). As Steve Conte pointed out, that is the address that used to be used for l.root-servers.net. l.root-servers.net was renumbered almost a year ago, with the announcement of the old address turned off about 6 months ago. > So the question is, should I just ignore this as a properly dropped > packet due to "no route" (this provider is running defaultless, so > unless such a route exists, it should be okay). Packets being sent to 198.32.64.12 most likely come from DNS caching servers that haven't had their hints updated. In the ideal world, you could hunt down those machines and kick 'em in the head (that is, install a new hints file). That they're unrouted is definitely the way things should be. Regards, -drc From vixie at isc.org Tue Sep 2 18:34:13 2008 From: vixie at isc.org (Paul Vixie) Date: Tue, 02 Sep 2008 23:34:13 +0000 Subject: "How the 'Net works: an introduction to peering and transit" (arstech) Message-ID: http://arstechnica.com/guides/other/peering-and-transit.ars -- Paul Vixie From kch670 at eecs.northwestern.edu Tue Sep 2 18:45:06 2008 From: kch670 at eecs.northwestern.edu (Kai Chen) Date: Tue, 2 Sep 2008 18:45:06 -0500 Subject: Is the export policy selective under valley-free? Message-ID: Just want to ask a direct question. Will an AS export all it gets from its customers and itself to its providers? Or even under valley-free, the BGP export policy is also selective? Thanks a lot, -- -Kai From pauldotwall at gmail.com Tue Sep 2 19:23:43 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Tue, 2 Sep 2008 20:23:43 -0400 Subject: Is the export policy selective under valley-free? In-Reply-To: References: Message-ID: <620fd17c0809021723w36693b2ctd3731a4bf706f5d9@mail.gmail.com> Kai, That's correct. A network purchasing transit will advertise its internally-originated prefixes, as well as those it's learning from downstream customers, to its provider. (At least that's the theory. It's not terribly uncommon for transit purchasers to advertise a full table, or for their providers to have lax or non-existent filters, but that's neither here nor there. :) I'm not sure what "valley-free" means in this context. You might want to try the Rosetta Stone patches and make sure your copy is up to date. Drive Slow, Paul Wall http://www.linkedin.com/in/paulwall On Tue, Sep 2, 2008 at 7:45 PM, Kai Chen wrote: > Just want to ask a direct question. Will an AS export all it gets from > its customers and itself to its providers? Or even under valley-free, > the BGP export policy is also selective? > > Thanks a lot, > -- > -Kai > > From todd-nanog at renesys.com Tue Sep 2 19:40:49 2008 From: todd-nanog at renesys.com (Todd Underwood) Date: Wed, 3 Sep 2008 00:40:49 +0000 Subject: 198.32.64.12 -- Harmless mis-route or potential exploit? In-Reply-To: <160A3E60-585D-4B34-88FE-8B09A8085893@virtualized.org> References: <160A3E60-585D-4B34-88FE-8B09A8085893@virtualized.org> Message-ID: <20080903004049.GC1602@renesys.com> dan, (to follow up on david conrad's response)... On Tue, Sep 02, 2008 at 04:31:40PM -0700, David Conrad wrote: > On Sep 2, 2008, at 3:24 PM, Dan Mahoney, System Admin wrote: > >While recently trying to debug a CEF issue, I found a good number of > >packets in my "debug cef drops" output that were all directed at > >198.32.64.12 (which I see as being allocated to ep.net but > >completely unused). > > As Steve Conte pointed out, that is the address that used to be used > for l.root-servers.net. l.root-servers.net was renumbered almost a > year ago, with the announcement of the old address turned off about 6 > months ago. there's some context on recent routing issues with this network described at the renesys blog here: http://www.renesys.com/blog/2008/06/securing_the_root_1.shtml in short: the prefix containing this network was advertised by people other than iana for a time after iana stopped advertising it. checking our current data, that block is not currently routed by any of our peers over the last month (i would assume ripe ris and routeviews report similar data, but i did not check them. t. -- _____________________________________________________________________ todd underwood +1 603 643 9300 x101 renesys corporation general manager babbledog todd at renesys.com http://www.renesys.com/blog From aaron.glenn at gmail.com Tue Sep 2 20:32:08 2008 From: aaron.glenn at gmail.com (Aaron Glenn) Date: Tue, 2 Sep 2008 18:32:08 -0700 Subject: 198.32.64.12 -- Harmless mis-route or potential exploit? In-Reply-To: References: Message-ID: <18f601940809021832i645ed403ta4370ca2b59e03ad@mail.gmail.com> On Tue, Sep 2, 2008 at 3:28 PM, Gadi Evron wrote: > My profile and resume: http://www.linkedin.com/in/gadievron are you for real? From coughes at gmail.com Tue Sep 2 20:35:26 2008 From: coughes at gmail.com (micky coughes) Date: Tue, 2 Sep 2008 21:35:26 -0400 Subject: 198.32.64.12 -- Harmless mis-route or potential exploit? In-Reply-To: <18f601940809021832i645ed403ta4370ca2b59e03ad@mail.gmail.com> References: <18f601940809021832i645ed403ta4370ca2b59e03ad@mail.gmail.com> Message-ID: <7bb79a490809021835v7cfa8345pe23c3303b562febb@mail.gmail.com> On Tue, Sep 2, 2008 at 9:32 PM, Aaron Glenn wrote: > On Tue, Sep 2, 2008 at 3:28 PM, Gadi Evron wrote: >> My profile and resume: http://www.linkedin.com/in/gadievron > > are you for real? > > No, he is not. From aaron.glenn at gmail.com Tue Sep 2 20:38:22 2008 From: aaron.glenn at gmail.com (Aaron Glenn) Date: Tue, 2 Sep 2008 18:38:22 -0700 Subject: Is the export policy selective under valley-free? In-Reply-To: References: Message-ID: <18f601940809021838s4a437a34q5903d3fa2b0d4acb@mail.gmail.com> On Tue, Sep 2, 2008 at 4:45 PM, Kai Chen wrote: > Just want to ask a direct question. Will an AS export all it gets from > its customers and itself to its providers? Or even under valley-free, > the BGP export policy is also selective? > that's the idea. but your use of valley-free in this context confuses me. care to clarify? From patrick at ianai.net Tue Sep 2 20:40:38 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 2 Sep 2008 21:40:38 -0400 Subject: self-promotion [was: 198.32.64.12 -- Harmless mis-route or potential exploit?] In-Reply-To: <620fd17c0809021544j189cb77al36a34ba970bb6463@mail.gmail.com> References: <620fd17c0809021544j189cb77al36a34ba970bb6463@mail.gmail.com> Message-ID: <55DE80DF-3901-4436-86F6-64DF50705506@ianai.net> On Sep 2, 2008, at 6:44 PM, Paul Wall wrote: > Could you please take the self-promotion offline already? Enough is > enough! I don't think anybody on this list is interested in hiring > you or reviewing your resume! > > (It could be argued that my post is off-topic as well. I disagree. > Furthermore, it had to be done, given the lack of public face or > consistent enforcement action of the current MLC.) [...] > Paul Wall > http://www.linkedin.com/in/paulwall > > On Tue, Sep 2, 2008 at 6:28 PM, Gadi Evron wrote: >> My profile and resume: http://www.linkedin.com/in/gadievron [SNIP] Just so that I am clear on your issue here: You believe it is "okay" for you to put your linkedin URL in your .sig, but Gadi must not be allowed to put it at the top of a post? I ask because I had to go back and read what you were so upset over since I did not even notice the first line in his post. I bet many others did not as well. Oh, and I think the fact it is L-Root's old IP address probably means no one will hire him to research it anyway. :-) -- TTFN, patrick From ge at linuxbox.org Tue Sep 2 20:48:52 2008 From: ge at linuxbox.org (Gadi Evron) Date: Tue, 2 Sep 2008 20:48:52 -0500 (CDT) Subject: 198.32.64.12 -- Harmless mis-route or potential exploit? In-Reply-To: <18f601940809021832i645ed403ta4370ca2b59e03ad@mail.gmail.com> References: <18f601940809021832i645ed403ta4370ca2b59e03ad@mail.gmail.com> Message-ID: On Tue, 2 Sep 2008, Aaron Glenn wrote: > On Tue, Sep 2, 2008 at 3:28 PM, Gadi Evron wrote: >> My profile and resume: http://www.linkedin.com/in/gadievron > > are you for real? > Yep. Are you a geek? I am that, too. Awkward, but easy to explain. I use PINE and I often have signatures added (which I barely ever actually use). PINE adds them at the footer of the message. Therefore I hit ctrl+K a few times and delete entire lines, then reply at the footer. I missed one line, which is the last of my current .signature file. My usual signature these days, as has been seen before on this list as well, is: ====== -- "You don't need your firewalls! Gadi is Israel's firewall." -- Itzik (Isaac) Cohen, "Computers czar", Senior Deputy to the Accountant General, Israel's Ministry of Finance, at the government's CIO conference, 2005. (after two very funny self-deprication quotes, time to even things up!) My profile and resume: http://www.linkedin.com/in/gadievron ====== So, you saw the last line. Awkward, but silly. You are an idiot just in case you wondered, as you now officially advertised a mistake nearly noi one noticed which is also advertising me. Yes? Back to our scheduled programming. Gadi. From smb at cs.columbia.edu Tue Sep 2 20:50:18 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Tue, 2 Sep 2008 21:50:18 -0400 Subject: self-promotion [was: 198.32.64.12 -- Harmless mis-route or potential exploit?] In-Reply-To: <55DE80DF-3901-4436-86F6-64DF50705506@ianai.net> References: <620fd17c0809021544j189cb77al36a34ba970bb6463@mail.gmail.com> <55DE80DF-3901-4436-86F6-64DF50705506@ianai.net> Message-ID: <20080902215018.07cfef0d@cs.columbia.edu> On Tue, 2 Sep 2008 21:40:38 -0400 "Patrick W. Gilmore" wrote: > [SNIP] > > Just so that I am clear on your issue here: You believe it is "okay" > for you to put your linkedin URL in your .sig, but Gadi must not be > allowed to put it at the top of a post? Yes, I think that's exactly right. It's a statement of what the sender perceives to be important about the email. I read email for the content; having the URL at the top is an assertion by the poster that he thinks his resume is more important than what he says. (Yes, I know some of you are about to hit reply to say "maybe it is from Gadi". Don't bother -- what he says is often quite valuable.) --Steve Bellovin, http://www.cs.columbia.edu/~smb From ops.lists at gmail.com Tue Sep 2 21:02:11 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 3 Sep 2008 07:32:11 +0530 Subject: GLBX De-Peers Intercage [Was: RE: Washington Post: Atrivo/Intercag e, w hy are we peering with the American RBN?] In-Reply-To: <20080901113321.666cf7aa@cs.columbia.edu> References: <20080901.014812.9559.0@webmail03.vgs.untd.com> <7679.1220261807@turing-police.cc.vt.edu> <48BBFA64.8020100@cox.net> <17826.1220281700@turing-police.cc.vt.edu> <20080901113321.666cf7aa@cs.columbia.edu> Message-ID: There's this concept known as "dual criminality" in such situations, when you're looking at international prosecutions (or whatever). So, while les? majest? - insult to the king - is a crime in thailand (liable to get you lynched before you get prosecuted, at that) that doesnt mean the thai authorities can do much about youtube videos .. On the other hand, child pornography, malware, illegal sale of prescription narcotics etc are generally criminal acts around the world. regards srs On Mon, Sep 1, 2008 at 9:03 PM, Steven M. Bellovin wrote: > I mostly agree with you -- but I get very worried about who defines > "scum". Consider the following cases, which I will assert are not very > far-fetched: > > (a) China labels Falun Gong as "scum" and demands that international > ISPs not carry it if they want to do business in China From morrowc.lists at gmail.com Tue Sep 2 21:08:10 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 2 Sep 2008 22:08:10 -0400 Subject: 198.32.64.12 -- Harmless mis-route or potential exploit? In-Reply-To: <20080903004049.GC1602@renesys.com> References: <160A3E60-585D-4B34-88FE-8B09A8085893@virtualized.org> <20080903004049.GC1602@renesys.com> Message-ID: <75cb24520809021908h6114592dsfd2f2bb4be657235@mail.gmail.com> On 9/2/08, Todd Underwood wrote: > checking our current data, that block is not currently routed by any > of our peers over the last month (i would assume ripe ris and > routeviews report similar data, but i did not check them. it's also probably worth stating that parts of 198.32/16 are never routed anywhere on the Internet (here comes bill to tell me 'who's Internet?' .....). Some is in use on private networks, some is in use at exchange points and not routed outside the immediate peers. Most times, as I recall, epnet does a decent job of keeping the whois data or rdns data updated though, for things in use. (though possibly not for private uses) -chris From ge at linuxbox.org Tue Sep 2 21:08:41 2008 From: ge at linuxbox.org (Gadi Evron) Date: Tue, 2 Sep 2008 21:08:41 -0500 (CDT) Subject: self-promotion [was: 198.32.64.12 -- Harmless mis-route or potential exploit?] In-Reply-To: <20080902215018.07cfef0d@cs.columbia.edu> References: <620fd17c0809021544j189cb77al36a34ba970bb6463@mail.gmail.com> <55DE80DF-3901-4436-86F6-64DF50705506@ianai.net> <20080902215018.07cfef0d@cs.columbia.edu> Message-ID: On Tue, 2 Sep 2008, Steven M. Bellovin wrote: > On Tue, 2 Sep 2008 21:40:38 -0400 > "Patrick W. Gilmore" wrote: > >> [SNIP] >> >> Just so that I am clear on your issue here: You believe it is "okay" >> for you to put your linkedin URL in your .sig, but Gadi must not be >> allowed to put it at the top of a post? > > Yes, I think that's exactly right. It's a statement of what the sender > perceives to be important about the email. I read email for the I agree, which is why this fluke in not deleting the last line with ctrk+k as PINE appends signature lines at the top of the post by default--was awkward. Good thing I don't much get deterred by awkward. Still, I bet this is going to be a huge thread yet again. No one appends any URL at the footer--not even me! ;) But folks with no content to contribute would naturally jump at it like they would at even just a typo. I suppose it is only natural when you become a celebrity of any sort--you draw all sorts of attention. At first my thick skin helped, nowadays I just find it amusing. Folks flooded mailing lists spoofing my name (creating ASCII art of Beavis or a swastika) using the subject lines. They flooded yet again, with furry porn pictures attached. They launched fan blogs, created an Encyclopedia Dramatica entry... I've had a comic strip made about me, a song written about me, a fake craigslist entry... all of course, serving as a boost to my ego--knowing "now I must have made it!" ;-) There was a blackhat presentation which in part was about how someone faked a social network account being me, and how he almost got an informationweek interview as me out of it--I was on to him. Most recently, someone created a comic-strip in ASCII about me (very funny, but R rated, so don't go if you find that type of thing offensive). It's from the "now I know I've made it!" department: http://fr.pastebin.ca/raw/1094119 To wrap this up, I don't often (at all) use signature lines, but I do have them and out of habit delete them with almost every new posting from the footer. I had two VERY self-depricating (and very funny) quotes, before, which also were not often used, anyone remember? 1. "beepbeep it, i leave work, stop reading sec lists and im still hearing gadi" - HD Moore to Gadi Evron on IM, on Gadi's interview on npr, March 2007. 2. *FART* -- Avi Freedman to Gadi Evron in a Chinese restaurant, Boston 2007. To even things out, my new barely ever used footer signature, is: ----- "You don't need your firewalls! Gadi is Israel's firewall." -- Itzik (Isaac) Cohen, "Computers czar", Senior Deputy to the Accountant General, Israel's Ministry of Finance, at the government's CIO conference, 2005. (after two very funny self-deprication quotes, time to even things up!) My profile and resume: http://www.linkedin.com/in/gadievron ------ So, I missed one line and it stuck at the footer and no one noticed it except the trolls. Now that the awkward moment is over and I made the unnecessary yet required explanation... can we move on? I really should use the man page and see how I move the signature from the footer in PINE. Thanks for the free advertisement of my resume, trolls! Appreciated. Gadi. > content; having the URL at the top is an assertion by the poster that > he thinks his resume is more important than what he says. (Yes, I know > some of you are about to hit reply to say "maybe it is from Gadi". > Don't bother -- what he says is often quite valuable.) > > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > From brunner at nic-naa.net Tue Sep 2 21:29:07 2008 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Tue, 02 Sep 2008 22:29:07 -0400 Subject: GLBX De-Peers Intercage [Was: RE: Washington Post: Atrivo/Intercag e, w hy are we peering with the American RBN?] In-Reply-To: References: <20080901.014812.9559.0@webmail03.vgs.untd.com> <7679.1220261807@turing-police.cc.vt.edu> <48BBFA64.8020100@cox.net> <17826.1220281700@turing-police.cc.vt.edu> <20080901113321.666cf7aa@cs.columbia.edu> Message-ID: <48BDF673.6050301@nic-naa.net> Suresh, In a parallel universe we're considering profiles for "licit use" of some mechanism. One element of a multi-part test to distinguish "licit" from "illicit" was the presence or absence of known signatures for malware. After some thought it was understood that this test was equivalent to the node subject to the test being "cleaner" than the average for network attached consumer devices, and therefore not realistic. Cheers, Eric Suresh Ramasubramanian wrote: > There's this concept known as "dual criminality" in such situations, > when you're looking at international prosecutions (or whatever). > > So, while les? majest? - insult to the king - is a crime in thailand > (liable to get you lynched before you get prosecuted, at that) that > doesnt mean the thai authorities can do much about youtube videos .. > > On the other hand, child pornography, malware, illegal sale of > prescription narcotics etc are generally criminal acts around the > world. > > regards > srs > > On Mon, Sep 1, 2008 at 9:03 PM, Steven M. Bellovin wrote: > >> I mostly agree with you -- but I get very worried about who defines >> "scum". Consider the following cases, which I will assert are not very >> far-fetched: >> >> (a) China labels Falun Gong as "scum" and demands that international >> ISPs not carry it if they want to do business in China >> > > > > From ops.lists at gmail.com Tue Sep 2 22:44:20 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 3 Sep 2008 09:14:20 +0530 Subject: GLBX De-Peers Intercage [Was: RE: Washington Post: Atrivo/Intercag e, w hy are we peering with the American RBN?] In-Reply-To: <48BDF673.6050301@nic-naa.net> References: <20080901.014812.9559.0@webmail03.vgs.untd.com> <7679.1220261807@turing-police.cc.vt.edu> <48BBFA64.8020100@cox.net> <17826.1220281700@turing-police.cc.vt.edu> <20080901113321.666cf7aa@cs.columbia.edu> <48BDF673.6050301@nic-naa.net> Message-ID: Eric, as you say, it is a multi part test. With fairly clear distinctions between a compromised node and one under the direct control of a criminal So while it is unrealistic when viewed in isolation, put together with other factors it starts to make a lot of sense. thanks srs On Wed, Sep 3, 2008 at 7:59 AM, Eric Brunner-Williams wrote: > In a parallel universe we're considering profiles for "licit use" of some > mechanism. One element of a multi-part test to distinguish "licit" from > "illicit" was the presence or absence of known signatures for malware. After > some thought it was understood that this test was equivalent to the node > subject to the test being "cleaner" than the average for network attached > consumer devices, and therefore not realistic. From emoazzam at gmail.com Wed Sep 3 01:53:48 2008 From: emoazzam at gmail.com (Moazzam Khan) Date: Wed, 3 Sep 2008 02:53:48 -0400 Subject: BGP Scalability Simulation In-Reply-To: References: <174dd5570809011257i20f0dedct8aa598daf6505ff0@mail.gmail.com> <174dd5570809021043o4d8f5322x86bb5b60bba9918e@mail.gmail.com> Message-ID: <174dd5570809022353p1033347bm2e11d33b162c924c@mail.gmail.com> Hi Ricardo, I checked the topologies from bgp tables at ucla site. These are in the form of huge tables . Can you please guide me how this can be utilized in the simulations. Regards MAK On Tue, Sep 2, 2008 at 2:04 PM, Ricardo Oliveira wrote: > The topos you mentioned are synthetic (e.g. generated based on math), you > might want to check these ones instead, based on bgp tables from public > sources: > http://irl.cs.ucla.edu/topology/ > > Also, i don't think using a full internet topology is the way to go to do > measure convergence time. The reason is that convergence time is highly > dependent on ibgp architecture, router timers, etc and modeling things as > one router per AS is at most unrealistic for this purpose. I would suggest > to look at a small yet realistic topology of a few ISPs, e.g. as given by > rocket fuel: > http://www.cs.washington.edu/research/networking/rocketfuel/ > > For routing table size, you just need to grab the existing available > routing tables, e.g. > http://www.routeviews.org/ > and do an extrapolation of the number of prefixes in RIB n years from now > > --Ricardo > > > > > On Sep 2, 2008, at 10:43 AM, Moazzam Khan wrote: > > Hi Ricardo, >> >> Basically I want to measure the Convergence times and routing table sizes. >> But I am not able to find a good topology of internet which I can utilize >> for my experimentations. I am looking at GT-ITM, BRITE and IGen but don't >> know what kind of abstraction they provide and if these topologies are >> feasible to test the above mentioned parameters. >> >> What challenges I can face if I want to measure all those parameters >> convergence times ,table sizes , update count, signal sizes etc. >> >> >> Regards >> Moazzam >> >> On Tue, Sep 2, 2008 at 1:35 PM, Ricardo Oliveira >> wrote: >> Moazzam, >> >> Do you have something specific in mind you want to measure? e.g. >> convergence times, table size, update count, etc? the scope of your study >> seems to broad as you describe it.. >> Cheers, >> >> --Ricardo >> >> >> On Sep 1, 2008, at 12:57 PM, Moazzam Khan wrote: >> >> Thanks Stefan for your reply. >> >> Basically the goal of this testing is to study the BGP scalability issues >> in >> the internet sometime in future lets say 10 years from now and try to find >> out what problems it could face . I am trying to use ns2 as my simulation >> environment. >> >> Can you suggest how I can set up the envrionment for this kind of study >> and >> what parameters should I try to caputre. >> >> Regards >> MAK >> >> On Mon, Sep 1, 2008 at 3:51 PM, Fouant, Stefan > >wrote: >> >> Topology and setup of these kinds of tests largely depend on whether you >> are testing iBGP or eBGP. In my experience, eBGP testing is fairly >> straight >> forward as you are almost always testing reconvergence of the BGP >> next-hop. >> iBGP testing scenarios on the other hand can be quite a bit more complex >> as >> you may also be testing the reconvergence of the underlying IGP if the BGP >> next-hop remains unchanged. Can you describe your testing goals and >> environment in a bit more detail? >> >> Stefan Fouant >> Principal Network Engineer >> NeuStar, Inc. - http://www.neustar.biz >> GPG Key ID: 0xB5E3803D >> >> >> ----- Original Message ----- >> From: Moazzam Khan >> To: nanog at nanog.org >> Sent: Mon Sep 01 15:37:19 2008 >> Subject: BGP Scalability Simulation >> >> Hi >> >> I am trying to simulate BGP for scalability testing. I have few queries. >> >> >> 1) What sort of topology I should try out ? >> >> 2) What parameters should I test? >> >> I am trying to simulate it in ns-2 and i would appreciate reply from you >> guys. >> >> Regards >> >> MAK >> >> >> >> >> > From ww at styx.org Wed Sep 3 03:36:52 2008 From: ww at styx.org (William Waites) Date: Wed, 3 Sep 2008 10:36:52 +0200 Subject: Is the export policy selective under valley-free? In-Reply-To: <620fd17c0809021723w36693b2ctd3731a4bf706f5d9@mail.gmail.com> References: <620fd17c0809021723w36693b2ctd3731a4bf706f5d9@mail.gmail.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 08-09-03 ? 02:23, Paul Wall a ?crit : > > That's correct. A network purchasing transit will advertise its > internally-originated prefixes, as well as those it's learning from > downstream customers, to its provider. > > I'm not sure what "valley-free" means in this context. You might want > to try the Rosetta Stone patches and make sure your copy is up to > date. Valley-free is a property of AS mesh models that says that, where edges are classified as peering (p2p) or transit (c2p) that a valid path contains zero or one peering link and that the peering link occurs adjacent to the top of the path. That is that valid paths look like, [c2p c2p ... c2p p2p p2c ... p2c p2c] (slightly abusing the notation for clarity) The idea is that a small, customer AS should not provide transit between its upstreams, though this does, apparently happen sometimes. Barring misconfigurations, I believe that AS paths are normally valley- free. See, for example, "Toward Valley-Free Inter-domain Routing" http://nsrc.cse.psu.edu/tech_report/NAS-TR-0054-2006.pdf "AS Relationships: Inference and Validation" http://www.caida.org/publications/papers/2006/as_relationships_inference/ Cheers, - -w - -- William Waites http://www.irl.styx.org/ +49 30 8894 9942 CD70 0498 8AE4 36EA 1CD7 281C 427A 3F36 2130 E9F5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAki+TKQACgkQQno/NiEw6fUsqQCeO4DN2glRopnWZwfgrhw1MdpZ 4kcAniuNr+O5KNl8GJKGM2C5RgHsd3ID =5AsJ -----END PGP SIGNATURE----- From iljitsch at muada.com Wed Sep 3 04:08:14 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 3 Sep 2008 11:08:14 +0200 Subject: Is the export policy selective under valley-free? In-Reply-To: References: Message-ID: <4EF4ADA5-960A-4B5E-8D56-A364E543046F@muada.com> On 3 sep 2008, at 1:45, Kai Chen wrote: > Just want to ask a direct question. Will an AS export all it gets from > its customers and itself to its providers? Or even under valley-free, > the BGP export policy is also selective? I get the valley-free but not the selective. :-) Iljitsch From ww at styx.org Wed Sep 3 04:29:52 2008 From: ww at styx.org (William Waites) Date: Wed, 3 Sep 2008 11:29:52 +0200 Subject: Is the export policy selective under valley-free? In-Reply-To: <4EF4ADA5-960A-4B5E-8D56-A364E543046F@muada.com> References: <4EF4ADA5-960A-4B5E-8D56-A364E543046F@muada.com> Message-ID: <118AB17C-DEA7-49AA-9E1C-E51798DAE326@styx.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 08-09-03 ? 11:08, Iljitsch van Beijnum a ?crit : > On 3 sep 2008, at 1:45, Kai Chen wrote: > >> Just want to ask a direct question. Will an AS export all it gets >> from >> its customers and itself to its providers? Or even under valley-free, >> the BGP export policy is also selective? > > I get the valley-free but not the selective. :-) (guessing) Suppose, C1 P1 \ / A / \ C2 P2 Suppose A has different policies for its two customers, such as, "announce C1 routes to P1 but not P2" and "announce C2 routes to P2 but not P1" In this case there would be valley-free paths [C1 A P2], [C2 A P1] that are not allowed because of A's policy. Though such a policy might be unusual, this is a case where the set of paths generated from the topology with the valley-free rule contains paths that would not occur in reality. I think that yes, the valley-free property is a necessary but not sufficient criteria for generating the set of in-reality-valid paths on the Internet. Cheers, - -w - -- William Waites http://www.irl.styx.org/ +49 30 8894 9942 CD70 0498 8AE4 36EA 1CD7 281C 427A 3F36 2130 E9F5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAki+WRAACgkQQno/NiEw6fW/bACeMoPGulTNd0+EiGesbTO8a3cX YfEAn2QOy9b3TVbA0t8CANp6BFPfcp8p =nYb4 -----END PGP SIGNATURE----- From randy at psg.com Wed Sep 3 04:40:32 2008 From: randy at psg.com (Randy Bush) Date: Wed, 03 Sep 2008 21:40:32 +1200 Subject: Is the export policy selective under valley-free? In-Reply-To: <118AB17C-DEA7-49AA-9E1C-E51798DAE326@styx.org> References: <4EF4ADA5-960A-4B5E-8D56-A364E543046F@muada.com> <118AB17C-DEA7-49AA-9E1C-E51798DAE326@styx.org> Message-ID: <48BE5B90.6040008@psg.com> > I think that yes, the valley-free property is a necessary but not > sufficient criteria for generating the set of in-reality-valid paths > on the Internet. i assure you that the actual topology is not valley free. e.g. there are many backup or political hack transit paths [0] between otherwise peers and there are also backup customer/provider reversals. often academic researchers assume the valley free condition to simplify their models. often this creates serious amusing in their results. randy, on holiday and should not be reading nanog, let alone responding From ww at styx.org Wed Sep 3 05:29:31 2008 From: ww at styx.org (William Waites) Date: Wed, 3 Sep 2008 12:29:31 +0200 Subject: Is the export policy selective under valley-free? In-Reply-To: <48BE5B90.6040008@psg.com> References: <4EF4ADA5-960A-4B5E-8D56-A364E543046F@muada.com> <118AB17C-DEA7-49AA-9E1C-E51798DAE326@styx.org> <48BE5B90.6040008@psg.com> Message-ID: <63720188-557D-4FDA-8C65-64181D66B2B3@styx.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08-09-03 at 11:40, Randy Bush on holiday and should not be reading nanog, let alone responding wrote : > i assure you that the actual topology is not valley free. e.g. there > are many backup or political hack transit paths [0] Sorry to further impinge on your vacation, but was there a footnote there? > between otherwise peers and there are also backup customer/provider > reversals. Perhaps the first case could be called misclassification of the edge by the link-labelling heuristics (and "otherwise peers" dropped)? But where such a relationship is symmetric it runs into the second case, and I agree that the model breaks down in the mutual transit scenario where a link can look like either c2p or p2c depending on the path being considered. How useful/productive is it to say that any observed path is always, by definition, valley-free and that the labels are not really properties of the graph but properties of the path? I'm not sure. Bonne vacances, - -w - -- William Waites http://www.irl.styx.org/ +49 30 8894 9942 CD70 0498 8AE4 36EA 1CD7 281C 427A 3F36 2130 E9F5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAki+ZwsACgkQQno/NiEw6fWETwCeMxiDOV+Par8Twua8bPbbUJKg liYAnjhqLfbPD7hjQZSmPnnJHdR9lmUn =5KOT -----END PGP SIGNATURE----- From iljitsch at muada.com Wed Sep 3 05:32:59 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 3 Sep 2008 12:32:59 +0200 Subject: Is the export policy selective under valley-free? In-Reply-To: <48BE5B90.6040008@psg.com> References: <4EF4ADA5-960A-4B5E-8D56-A364E543046F@muada.com> <118AB17C-DEA7-49AA-9E1C-E51798DAE326@styx.org> <48BE5B90.6040008@psg.com> Message-ID: On 3 sep 2008, at 11:40, Randy Bush wrote: >> I think that yes, the valley-free property is a necessary but not >> sufficient criteria for generating the set of in-reality-valid paths >> on the Internet. > i assure you that the actual topology is not valley free. e.g. there > are many backup or political hack transit paths [0] between otherwise > peers and there are also backup customer/provider reversals. often > academic researchers assume the valley free condition to simplify > their > models. often this creates serious amusing in their results. Note that valley-freeness is possible in the presence of backup configurations, which are usually called "sibling" relationships in this context. The basis for the valley-freeness rules is the paper "Stable Internet Routing Without Global Coordination" by Lixin Gao and Jennifer Rexford, although the term isn't used in this paper. They start out with Guideline A which says that customers must have a higher local preference than peers. If everyone uses policies like this then BGP will provably converge to a single stable state. But there's more. Assumption P is about clusters of ASes that peer with each other (possibly indirectly). ASes that don't peer are a cluster of their own. Assumption P is then that the graph of these is a directed acyclic graph: = when you follow the provider->customer relationships there are no cycles in the topology and there are no "self cycles". I guess this means you don't sell transit to yourself... or your peers. (Note that it's possible to have one type of relationship for one prefix and another for another prefix, so a European and American network can sell each other transit for their home region and peer for Asian traffic and still conform to the assumption.) With Assumption P in place Guideline A can be relaxed (as Guideline B) such that peers and customers may now have the same local preference. The next step is Guidelince C which allows for mutual backup relationships. Any path that has a hop with a backup link in it is considered a backup path and must have a single local preference value that is lower than that of any non-backup paths. "Note that, unlike Guideline A or B, enforcing Guideline C requires cooperation between ASs. An AS can not tell which routes involve backup links between other AS pairs. Hence, the BGP advertisements must identify these routes. This is typically achieved using the community attribute". So... I guess if we all set and recognize that "IHAZBACKUP" community we should be safe. Oh wait: http://www.iana.org/assignments/bgp-well-known-communities/ From bmanning at vacation.karoshi.com Wed Sep 3 07:36:12 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 3 Sep 2008 12:36:12 +0000 Subject: GLBX De-Peers Intercage [Was: RE: Washington Post: Atrivo/Intercag e, w hy are we peering with the American RBN?] In-Reply-To: <48BBFA64.8020100@cox.net> References: <20080901.014812.9559.0@webmail03.vgs.untd.com> <7679.1220261807@turing-police.cc.vt.edu> <48BBFA64.8020100@cox.net> Message-ID: <20080903123612.GA18369@vacation.karoshi.com.> On Mon, Sep 01, 2008 at 09:21:24AM -0500, Laurence F. Sheldon, Jr. wrote: > Valdis.Kletnieks at vt.edu wrote: > >On Mon, 01 Sep 2008 08:48:12 -0000, Paul Ferguson said: > > >>Is this an issue that network operations folk don't really care > >>about? > > > >If somebody's paying you $n/megabyte for transit/connectivity, what's your > >incentive to make them clean up their act and get rid of their P2P > >filesharing > >traffic, spam traffic, and so on? > > What is your price for cocaine? > well... http://www.narcoticnews.com/Cocaine/Prices/USA/Cocaine_Prices_USA.html has some pointers - if your shopping. --bill From bmanning at vacation.karoshi.com Wed Sep 3 07:42:48 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 3 Sep 2008 12:42:48 +0000 Subject: 198.32.64.12 -- Harmless mis-route or potential exploit? In-Reply-To: References: Message-ID: <20080903124248.GB18369@vacation.karoshi.com.> well, actually.... this was the IP address used for l.root-servers.net from 1998-2008. so i guess you could say its never been used for anything. we are not currently routing that prefix and there should currently be nothing at that IP address. --bill On Tue, Sep 02, 2008 at 06:24:21PM -0400, Dan Mahoney, System Admin wrote: > Hello all, > > While recently trying to debug a CEF issue, I found a good number of > packets in my "debug cef drops" output that were all directed at > 198.32.64.12 (which I see as being allocated to ep.net but completely > unused). > > Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route > Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route > Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route > Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route > Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route > Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route > Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route > Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route > > Now, as nearly as I can tell, this IP address has never been used for > anything, but I see occasional references to it, such as here: > > http://www.honeynet.org/papers/forensics/exploit.html > > So the question is, should I just ignore this as a properly dropped packet > due to "no route" (this provider is running defaultless, so unless such a > route exists, it should be okay). > > On the other hand, one of the other packets I'm seeing specifically refers > to a DNS exploit, so should I then dispatch to people to trace down the > source origin ? (Suffice it to say the resources are there to find it > fairly easily, even if the source address is forged). > > -Dan > > -- > > --------Dan Mahoney-------- > Techie, Sysadmin, WebGeek > Gushi on efnet/undernet IRC > ICQ: 13735144 AIM: LarpGM > Site: http://www.gushi.org > --------------------------- > From bmanning at vacation.karoshi.com Wed Sep 3 07:48:30 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 3 Sep 2008 12:48:30 +0000 Subject: 198.32.64.12 -- Harmless mis-route or potential exploit? In-Reply-To: <75cb24520809021908h6114592dsfd2f2bb4be657235@mail.gmail.com> References: <160A3E60-585D-4B34-88FE-8B09A8085893@virtualized.org> <20080903004049.GC1602@renesys.com> <75cb24520809021908h6114592dsfd2f2bb4be657235@mail.gmail.com> Message-ID: <20080903124830.GD18369@vacation.karoshi.com.> On Tue, Sep 02, 2008 at 10:08:10PM -0400, Christopher Morrow wrote: > On 9/2/08, Todd Underwood wrote: > > > checking our current data, that block is not currently routed by any > > of our peers over the last month (i would assume ripe ris and > > routeviews report similar data, but i did not check them. > > it's also probably worth stating that parts of 198.32/16 are never > routed anywhere on the Internet (here comes bill to tell me 'who's > Internet?' .....). Some is in use on private networks, some is in use > at exchange points and not routed outside the immediate peers. grump... ok... "who's internet"? > Most times, as I recall, epnet does a decent job of keeping the whois > data or rdns data updated though, for things in use. (though possibly > not for private uses) rdns moreso that whois... > > -chris From jgreco at ns.sol.net Wed Sep 3 08:02:09 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 3 Sep 2008 08:02:09 -0500 (CDT) Subject: self-promotion [was: 198.32.64.12 -- Harmless mis-route or In-Reply-To: <20080902215018.07cfef0d@cs.columbia.edu> from "Steven M. Bellovin" at Sep 02, 2008 09:50:18 PM Message-ID: <200809031302.m83D29bk063494@aurora.sol.net> > > [SNIP] > > > > Just so that I am clear on your issue here: You believe it is "okay" > > for you to put your linkedin URL in your .sig, but Gadi must not be > > allowed to put it at the top of a post? > > Yes, I think that's exactly right. It's a statement of what the sender > perceives to be important about the email. I read email for the > content; having the URL at the top is an assertion by the poster that > he thinks his resume is more important than what he says. (Yes, I know > some of you are about to hit reply to say "maybe it is from Gadi". > Don't bother -- what he says is often quite valuable.) > > --Steve Bellovin, http://www.cs.columbia.edu/~smb Patrick, I would say that "we" have a long history of tolerating certain content within a signature that might not be appropriate within a message itself; my own opinion would be that inclusion of this sort of thing outside of the signature is inappropriate, except perhaps where it would fall within the scope of the purpose of the list. Steve, it is intriguing that you would make such a statement, since you clearly believe that your own signature is sufficiently worthwhile that you do not separate it from the main message with a signature separator, which would cause those of us who have clients configured to grey out or eliminate signatures to ignore "less valuable" signature content. I do appreciate that your signature is refreshingly brief, however. ;-) Paul, who I believe originally complained about this, I would have agreed with your complaint had it clearly been part of a pattern of behaviour on Gadi's part. However, a one-time inclusion of unacceptable text should probably be overlooked. There are very few of us who have /never/ made a cut and paste error, failed to trim content, misattributed a message, failed to attribute a message, or made any of a hundred other minor sins. You wouldn't want a bunch of us to pile on you the next time you make a speeling mysteak. You might also want to make sure you put your LinkedIn URL in your SIGNATURE, after a signature separator, because from where I sit, your message closely resembles Gadi's, because you included a LI URL in the BODY of your message. Gadi, you do have an aura that surrounds you of vague self-promotion, and you seem to rub some people the wrong way. You might want to consider not including an automatic signature if you don't intend to use it on a majority of messages, because clearly there is a chance of operator error when deleting the unintended text. Joe, you obnoxious jerk, you include TWO signatures in your messages, one "initials only" one before the signature separator, and a fully compliant one after. Pick one or the other! ("But it helps clarify attributions, etc!") ;-) There. Now we have a mountain made out of a molehill! Now back to our regularly scheduled programming. (*groan*) ... 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 Wed Sep 3 08:24:12 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Wed, 3 Sep 2008 09:24:12 -0400 Subject: self-promotion [was: 198.32.64.12 -- Harmless mis-route or In-Reply-To: <200809031302.m83D29bk063494@aurora.sol.net> References: <20080902215018.07cfef0d@cs.columbia.edu> <200809031302.m83D29bk063494@aurora.sol.net> Message-ID: <20080903092412.3aa8af5d@yellowstone.machshav.com> On Wed, 3 Sep 2008 08:02:09 -0500 (CDT) Joe Greco wrote: > Steve, it is intriguing that you would make such a statement, since > you clearly believe that your own signature is sufficiently > worthwhile that you do not separate it from the main message with a > signature separator, which would cause those of us who have clients > configured to grey out or eliminate signatures to ignore "less > valuable" signature content. I do appreciate that your signature is > refreshingly brief, however. ;-) It's in the interest of brevity... --Steve Bellovin, http://www.cs.columbia.edu/~smb From morrowc.lists at gmail.com Wed Sep 3 09:00:41 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 3 Sep 2008 10:00:41 -0400 Subject: 198.32.64.12 -- Harmless mis-route or potential exploit? In-Reply-To: <20080903124830.GD18369@vacation.karoshi.com.> References: <160A3E60-585D-4B34-88FE-8B09A8085893@virtualized.org> <20080903004049.GC1602@renesys.com> <75cb24520809021908h6114592dsfd2f2bb4be657235@mail.gmail.com> <20080903124830.GD18369@vacation.karoshi.com.> Message-ID: <75cb24520809030700s63dba2a1xb7e54e7d3eb2c99@mail.gmail.com> On Wed, Sep 3, 2008 at 8:48 AM, wrote: > On Tue, Sep 02, 2008 at 10:08:10PM -0400, Christopher Morrow wrote: >> On 9/2/08, Todd Underwood wrote: >> >> > checking our current data, that block is not currently routed by any >> > of our peers over the last month (i would assume ripe ris and >> > routeviews report similar data, but i did not check them. >> >> it's also probably worth stating that parts of 198.32/16 are never >> routed anywhere on the Internet (here comes bill to tell me 'who's >> Internet?' .....). Some is in use on private networks, some is in use >> at exchange points and not routed outside the immediate peers. > > grump... ok... "who's internet"? there he is!!! :) (thanks for restoring my faith in... humanity) > >> Most times, as I recall, epnet does a decent job of keeping the whois >> data or rdns data updated though, for things in use. (though possibly >> not for private uses) > > rdns moreso that whois... 198.32.64.12 == AS-20144-has-not-REGISTERED-the-use-of-this-prefix. for instance? -chris From kch670 at eecs.northwestern.edu Wed Sep 3 10:11:10 2008 From: kch670 at eecs.northwestern.edu (Kai Chen) Date: Wed, 3 Sep 2008 10:11:10 -0500 Subject: Is the export policy selective under valley-free? In-Reply-To: <118AB17C-DEA7-49AA-9E1C-E51798DAE326@styx.org> References: <4EF4ADA5-960A-4B5E-8D56-A364E543046F@muada.com> <118AB17C-DEA7-49AA-9E1C-E51798DAE326@styx.org> Message-ID: On Wed, Sep 3, 2008 at 4:29 AM, William Waites wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Le 08-09-03 ? 11:08, Iljitsch van Beijnum a ?crit : > >> On 3 sep 2008, at 1:45, Kai Chen wrote: >> >>> Just want to ask a direct question. Will an AS export all it gets from >>> its customers and itself to its providers? Or even under valley-free, >>> the BGP export policy is also selective? >> >> I get the valley-free but not the selective. :-) > > > (guessing) > > Suppose, > > C1 P1 > \ / > A > / \ > C2 P2 > > Suppose A has different policies for its two customers, such as, "announce > C1 routes to P1 but not P2" and "announce C2 routes to P2 but not P1" > This is exactly what I think? But I am not sure if it is ture. My observation is that Routeviews cannot see a lot p2c(c2p) links which they should see if it is strict "valley-free" --- an AS will export all its customers to every neighbor. > In this case there would be valley-free paths [C1 A P2], [C2 A P1] that are > not allowed because of A's policy. Though such a policy might be unusual, > this is a case where the set of paths generated from the topology with the > valley-free rule contains paths that would not occur in reality. > > I think that yes, the valley-free property is a necessary but not sufficient > criteria for generating the set of in-reality-valid paths on the Internet. > > Cheers, > - -w > - -- > William Waites > http://www.irl.styx.org/ +49 30 8894 9942 > CD70 0498 8AE4 36EA 1CD7 281C 427A 3F36 2130 E9F5 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (Darwin) > > iEYEARECAAYFAki+WRAACgkQQno/NiEw6fW/bACeMoPGulTNd0+EiGesbTO8a3cX > YfEAn2QOy9b3TVbA0t8CANp6BFPfcp8p > =nYb4 > -----END PGP SIGNATURE----- > -- -Kai From hobbit at avian.org Wed Sep 3 10:16:17 2008 From: hobbit at avian.org (*Hobbit*) Date: Wed, 3 Sep 2008 15:16:17 +0000 (GMT) Subject: ingress SMTP Message-ID: <20080903151617.A14277808@relayer.avian.org> I've been blackholing NANOG mail for a while due to other things displacing the time I'd need to read it, so I might be a little out of touch on this, but I did grovel through some of the archives looking for any discussion on this before posting. Didn't find a really coherent answer yet. What I'm trying to get a feel for is this: what proportion of edge customers have a genuine NEED to send direct SMTP traffic to TCP 25 at arbitrary destinations? I'm thinking mostly of cable-modem and DSL/fiber swamps, dialup pools [do they even exist anymore?], and other clouds basically containing end-users rather than the more "bidirectional" business-class customers. The big providers -- comcast, verizon, RR, charter, bellsouth, etc -- seem to be some of the most significant sources of spam and malware attempts, mostly from compromised end-user machines, and it seems that simply denying *INGRESS* of TCP 25 traffic except to the given ISP's outbound relay servers would cut an awful lot of it off at the pass. Decent anti-header-spoofing configuration on said mailservers would take care of even more. I realize this might be a total hot-button but I'm not talking about filtering TOWARD customers, I'm talking about filtering FROM them, upstream -- possibly less often discussed. And only SMTP. Not censorship, just a simple technical policy that the vast majority of customers wouldn't even notice. I've got a paper out about this that was put together quite a while ago, in fact: http://www.usenix.org/publications/login/2005-10/openpdfs/hobbit.pdf I can weigh the decision to trust a PTR lookup, but most of the big players seem to have their inverse DNS automated fairly well which helps such little hacks work. But really, I'd like to see more done at the SOURCE of the problem, which should be as simple as two ACL lines dropped into some edge routers. What is preventing this from being an operational no-brainer, including making a few exceptions for customers that prove they know how to lock down their own mail infrastructure? And why do the largest players seem to have the least clue about it? _H* From ops.lists at gmail.com Wed Sep 3 10:50:31 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 3 Sep 2008 21:20:31 +0530 Subject: ingress SMTP In-Reply-To: <20080903151617.A14277808@relayer.avian.org> References: <20080903151617.A14277808@relayer.avian.org> Message-ID: On Wed, Sep 3, 2008 at 8:46 PM, *Hobbit* wrote: > > What I'm trying to get a feel for is this: what proportion of edge > customers have a genuine NEED to send direct SMTP traffic to TCP 25 > at arbitrary destinations? I'm thinking mostly of cable-modem and Not too many - they got themselves port 587 to submit outbound mail. Read the maawg managing port 25 document - and while you are at it read the walled garden doc too.. port 25 abuse is the least of your worries with cable/dsl cpe swamps http://www.maawg.org/port25 http://www.maawg.org/about/whitepapers/MAAWG_Walled_Garden_BP_2007-09.pdf --srs From tims at donet.com Wed Sep 3 10:52:48 2008 From: tims at donet.com (Tim Sanderson) Date: Wed, 3 Sep 2008 11:52:48 -0400 Subject: ingress SMTP In-Reply-To: <20080903151617.A14277808@relayer.avian.org> References: <20080903151617.A14277808@relayer.avian.org> Message-ID: Anybody not wanting to use their ISP email would notice it. I see filtering 25 FROM the customer as something that is not likely to happen because of this. When a customer buys bandwidth, they want to be able to use it for whatever they choose. This would be just one more restriction giving competitive advantage to any ISP not doing the filtering. -- Tim Sanderson, network administrator tims at donet.com -----Original Message----- From: *Hobbit* [mailto:hobbit at avian.org] Sent: Wednesday, September 03, 2008 11:16 AM To: nanog at nanog.org Subject: ingress SMTP I've been blackholing NANOG mail for a while due to other things displacing the time I'd need to read it, so I might be a little out of touch on this, but I did grovel through some of the archives looking for any discussion on this before posting. Didn't find a really coherent answer yet. What I'm trying to get a feel for is this: what proportion of edge customers have a genuine NEED to send direct SMTP traffic to TCP 25 at arbitrary destinations? I'm thinking mostly of cable-modem and DSL/fiber swamps, dialup pools [do they even exist anymore?], and other clouds basically containing end-users rather than the more "bidirectional" business-class customers. The big providers -- comcast, verizon, RR, charter, bellsouth, etc -- seem to be some of the most significant sources of spam and malware attempts, mostly from compromised end-user machines, and it seems that simply denying *INGRESS* of TCP 25 traffic except to the given ISP's outbound relay servers would cut an awful lot of it off at the pass. Decent anti-header-spoofing configuration on said mailservers would take care of even more. I realize this might be a total hot-button but I'm not talking about filtering TOWARD customers, I'm talking about filtering FROM them, upstream -- possibly less often discussed. And only SMTP. Not censorship, just a simple technical policy that the vast majority of customers wouldn't even notice. I've got a paper out about this that was put together quite a while ago, in fact: http://www.usenix.org/publications/login/2005-10/openpdfs/hobbit.pdf I can weigh the decision to trust a PTR lookup, but most of the big players seem to have their inverse DNS automated fairly well which helps such little hacks work. But really, I'd like to see more done at the SOURCE of the problem, which should be as simple as two ACL lines dropped into some edge routers. What is preventing this from being an operational no-brainer, including making a few exceptions for customers that prove they know how to lock down their own mail infrastructure? And why do the largest players seem to have the least clue about it? _H* From jscott at gravityfree.com Wed Sep 3 10:56:51 2008 From: jscott at gravityfree.com (Justin Scott) Date: Wed, 03 Sep 2008 11:56:51 -0400 Subject: ingress SMTP In-Reply-To: <20080903151617.A14277808@relayer.avian.org> References: <20080903151617.A14277808@relayer.avian.org> Message-ID: <48BEB3C3.1070600@gravityfree.com> > What is preventing this from being an operational no-brainer, > including making a few exceptions for customers that prove they know > how to lock down their own mail infrastructure? As a small player who operates a mail server used by many local businesses, this becomes a support issue for admins in our position. We operate an SMTP server of our own that the employees of these various companies use from work and at home. Everything works great until an ISP decides to block 25 outbound. Now our customer cannot reach our server, so they call us to complain that they can receive but not send e-mail. We, being somewhat intelligent, have a support process in place to walk the customer through the SMTP port change from 25 to one of our two alternate ports. The problem, however, is that the customer simply cannot understand why their e-mail worked one day and doesn't the next. In their eyes the system used to work, and now it doesn't, so that must mean that we broke it and that we don't know what we're doing. Your comment about "exceptions for customers that prove they know how to lock down" is not based in reality, frankly. Have you ever tried to have Joe Sixpack call BigISP support to ask for an exception to a port block on his consumer-class connection with a dynamic IP? That's a wall that I would not be willing to ask my customers to climb over. Now, having said all that, I do agree that big ISPs should do more to prevent spam from originating at their networks. A basic block of 25 isn't the solution, in my opinion. Unfortunately I don't know what is. Perhaps monitoring the number of outgoing connections on 25 and temporarily cutting off access if a threshold is reached? Set it high enough and the legitimate users won't notice, but low enough that it disrupts the spammers. Perhaps I'm talking out of my ass and don't have a clue. In any case, I don't believe a blanket block of 25 is the answer. -Justin Scott, GravityFree -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3257 bytes Desc: S/MIME Cryptographic Signature URL: From jra at baylink.com Wed Sep 3 11:06:44 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Wed, 3 Sep 2008 12:06:44 -0400 Subject: ingress SMTP In-Reply-To: References: <20080903151617.A14277808@relayer.avian.org> Message-ID: <20080903160644.GH8979@cgi.jachomes.com> On Wed, Sep 03, 2008 at 11:52:48AM -0400, Tim Sanderson wrote: > Anybody not wanting to use their ISP email would notice it. I see > filtering 25 FROM the customer as something that is not likely to > happen because of this. When a customer buys bandwidth, they want to > be able to use it for whatever they choose. This would be just one > more restriction giving competitive advantage to any ISP not doing the > filtering. Just as long as consumer ISPs don't start filtering *110* inbound from the net... as AT&T used to. I had a client move from dialup to cablemodem about 10 years ago... and it took us a *week* to get AT&T to admit they didn't accept inbound POP pickups. Client (intemperately) had printed the att.com email address of lots of crap -- they had to keep the dialup for a long time, since at&t wouldn't forward either... Thank ghod I'm out of the jungle 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 alec.berry at restontech.com Wed Sep 3 11:06:45 2008 From: alec.berry at restontech.com (Alec Berry) Date: Wed, 03 Sep 2008 12:06:45 -0400 Subject: ingress SMTP In-Reply-To: <48BEB3C3.1070600@gravityfree.com> References: <20080903151617.A14277808@relayer.avian.org> <48BEB3C3.1070600@gravityfree.com> Message-ID: <48BEB615.3060202@restontech.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Justin Scott wrote: > We, being somewhat intelligent, have a support process in place > to walk the customer through the SMTP port change from 25 to one of our > two alternate ports. Why don't you set the alternate ports up as the defaults when the customer signs up? There are so many ISPs, WAPs, cell carriers, etc that are blocking egress port 25 (ie outgoing from their network) already. The prudent thing to do, for you and your customers, would be to assume every customer will, at some point, have access to port 25 blocked. We use TLS on port 587 and SSL on 465, most mail clients default to these ports when you click the "TLS" or "SSL" box. Bonus-- we tell our clients that "we only support encrypted access to their mail". They understand. > In any case, I don't believe a blanket block of 25 is the answer. If the question is "how can we stop consumer bot armies from sending spam" it is a pretty good, albeit incomplete, answer. ... alec - -- `____________ / Alec Berry \______________________________ | Senior Partner and Director of Technology \ | PGP/GPG key 0xE8E9030F | | http://alec.restontech.com/#PGP | |-------------------------------------------| | RestonTech, Ltd. | | http://www.restontech.com/ | | Phone: (703) 234-2914 | \___________________________________________/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIvrYTREO1P+jpAw8RApsOAJ9YTMfMfb4X4PDVaABd+jeLiU/3IgCeKLQW 7rczuS4j56owjGJ88RQbV4I= =le+L -----END PGP SIGNATURE----- From ahodgson at simkin.ca Wed Sep 3 11:13:10 2008 From: ahodgson at simkin.ca (Alan Hodgson) Date: Wed, 3 Sep 2008 09:13:10 -0700 Subject: ingress SMTP In-Reply-To: <48BEB3C3.1070600@gravityfree.com> References: <20080903151617.A14277808@relayer.avian.org> <48BEB3C3.1070600@gravityfree.com> Message-ID: <200809030913.10923@hal.medialogik.com> On Wednesday 03 September 2008, Justin Scott wrote: > The problem, however, is that the customer simply cannot understand why > their e-mail worked one day and doesn't the next. In their eyes the > system used to work, and now it doesn't, so that must mean that we broke > it and that we don't know what we're doing. You don't. They should have been setup on port 587 to start with. -- Alan From jra at baylink.com Wed Sep 3 11:14:00 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Wed, 3 Sep 2008 12:14:00 -0400 Subject: ingress SMTP In-Reply-To: <48BEB3C3.1070600@gravityfree.com> References: <20080903151617.A14277808@relayer.avian.org> <48BEB3C3.1070600@gravityfree.com> Message-ID: <20080903161400.GI8979@cgi.jachomes.com> On Wed, Sep 03, 2008 at 11:56:51AM -0400, Justin Scott wrote: > As a small player who operates a mail server used by many local > businesses, this becomes a support issue for admins in our position. We > operate an SMTP server of our own that the employees of these various > companies use from work and at home. Everything works great until an > ISP decides to block 25 outbound. Now our customer cannot reach our > server, so they call us to complain that they can receive but not send > e-mail. We, being somewhat intelligent, have a support process in place > to walk the customer through the SMTP port change from 25 to one of our > two alternate ports. > > The problem, however, is that the customer simply cannot understand why > their e-mail worked one day and doesn't the next. In their eyes the > system used to work, and now it doesn't, so that must mean that we broke > it and that we don't know what we're doing. I feel your pain, local compadre, but I'm on their side. Here's your script: "Allowing unfiltered public access to port 25 is one of the things that increases everyone's spam load, and your ISP is trying to be a Good Neighbor in blocking access to anyone's servers but their own; many ISPs are moving towards this safer configuration. We're a good neighbor, as well, and support Mail Submission Protocol on port 587, and here's how you set it up -- and it will work from pretty much anywhere forever." Which is a safe thing to tell people because it is decidedly *not* best practice to block 587. 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 jscott at gravityfree.com Wed Sep 3 11:32:39 2008 From: jscott at gravityfree.com (Justin Scott) Date: Wed, 03 Sep 2008 12:32:39 -0400 Subject: ingress SMTP In-Reply-To: <48BEB615.3060202@restontech.com> References: <20080903151617.A14277808@relayer.avian.org> <48BEB3C3.1070600@gravityfree.com> <48BEB615.3060202@restontech.com> Message-ID: <48BEBC27.9000004@gravityfree.com> > Why don't you set the alternate ports up as the defaults when the > customer signs up? Excellent question and unfortunately I don't have an answer. I will run that one by management as it is an obviously great idea now that you mention it. > We use TLS on port 587 and SSL on 465, most mail clients default to > these ports when you click the "TLS" or "SSL" box. Bonus-- we tell our > clients that "we only support encrypted access to their mail". They > understand. We also support SSL access for SMTP and POP, so that could be a possibility as well. I appreciate the feedback on this from everyone. I'm still not 100% convinced that a blanket port block is the answer, but then again I'm not an ISP so my opinion shouldn't be on the top of the list of considerations either. I do have some things to think about for new customers though . -Justin Scott, GravityFree -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3257 bytes Desc: S/MIME Cryptographic Signature URL: From mike at mtcc.com Wed Sep 3 11:40:20 2008 From: mike at mtcc.com (Michael Thomas) Date: Wed, 03 Sep 2008 09:40:20 -0700 Subject: ingress SMTP In-Reply-To: <20080903161400.GI8979@cgi.jachomes.com> References: <20080903151617.A14277808@relayer.avian.org> <48BEB3C3.1070600@gravityfree.com> <20080903161400.GI8979@cgi.jachomes.com> Message-ID: <48BEBDF4.9040109@mtcc.com> Jay R. Ashworth wrote: > On Wed, Sep 03, 2008 at 11:56:51AM -0400, Justin Scott wrote: > >> As a small player who operates a mail server used by many local >> businesses, this becomes a support issue for admins in our position. We >> operate an SMTP server of our own that the employees of these various >> companies use from work and at home. Everything works great until an >> ISP decides to block 25 outbound. Now our customer cannot reach our >> server, so they call us to complain that they can receive but not send >> e-mail. We, being somewhat intelligent, have a support process in place >> to walk the customer through the SMTP port change from 25 to one of our >> two alternate ports. >> >> The problem, however, is that the customer simply cannot understand why >> their e-mail worked one day and doesn't the next. In their eyes the >> system used to work, and now it doesn't, so that must mean that we broke >> it and that we don't know what we're doing. >> > > I feel your pain, local compadre, but I'm on their side. > > Here's your script: > > "Allowing unfiltered public access to port 25 is one of the things that > increases everyone's spam load, and your ISP is trying to be a Good > Neighbor in blocking access to anyone's servers but their own; many ISPs > are moving towards this safer configuration. We're a good neighbor, as > well, and support Mail Submission Protocol on port 587, and here's how > you set it up -- and it will work from pretty much anywhere forever." > > I think this all vastly underrates the agility of the bad guys. So lots of ISP's have blocked port 25. Has it made any appreciable difference? Not that I can tell. If you block port 25, they'll just use another port and a relay if necessary. But the thing that's really pernicious about this sort of policy is that it's a back door policy for ISP's to clamp down on all outgoing ports in the name of "security". And it's almost plausible, except for the annoying problem that the net becomes secure and useless in one swell foop. That said, I heard a pretty amazing claim made by somebody while I was still at the big ol networking company that ISP's in general not only didn't know which of their customers computers were owned, but that they didn't want to know. Even putting aside the claim of blissful ignorance, port 25 blocking is nothing more than a Maginot Line for the larger problems of infected computers. If we really wanted to curb spam, why don't we just put them in the penalty box until they are remediated? Heck, that even stops lots of other attacks that have nothing to do with port 25 too. Mike From ops.lists at gmail.com Wed Sep 3 11:41:55 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 3 Sep 2008 22:11:55 +0530 Subject: ingress SMTP In-Reply-To: <48BEB3C3.1070600@gravityfree.com> References: <20080903151617.A14277808@relayer.avian.org> <48BEB3C3.1070600@gravityfree.com> Message-ID: On Wed, Sep 3, 2008 at 9:26 PM, Justin Scott wrote: >> What is preventing this from being an operational no-brainer, >> including making a few exceptions for customers that prove they know >> how to lock down their own mail infrastructure? > > As a small player who operates a mail server used by many local businesses, > this becomes a support issue for admins in our position. We operate an SMTP Do you operate your mailserver on a residential cablemodem or adsl rather than a business account? There's this little matter of a "no servers on home connections" type AUP that most providers have .. --srs From jscott at gravityfree.com Wed Sep 3 11:48:42 2008 From: jscott at gravityfree.com (Justin Scott) Date: Wed, 03 Sep 2008 12:48:42 -0400 Subject: ingress SMTP In-Reply-To: References: <20080903151617.A14277808@relayer.avian.org> <48BEB3C3.1070600@gravityfree.com> Message-ID: <48BEBFEA.102@gravityfree.com> > Do you operate your mailserver on a residential cablemodem or adsl > rather than a business account? No, we co-lo equipment at a professional facility that our customers on any type of connection need to have access to send mail through, regardless of whether their ISP blocks the standard ports or not. -Justin Scott, GravityFree -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3257 bytes Desc: S/MIME Cryptographic Signature URL: From jra at baylink.com Wed Sep 3 11:49:41 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Wed, 3 Sep 2008 12:49:41 -0400 Subject: ingress SMTP In-Reply-To: <48BEBDF4.9040109@mtcc.com> References: <20080903151617.A14277808@relayer.avian.org> <48BEB3C3.1070600@gravityfree.com> <20080903161400.GI8979@cgi.jachomes.com> <48BEBDF4.9040109@mtcc.com> Message-ID: <20080903164941.GL8979@cgi.jachomes.com> On Wed, Sep 03, 2008 at 09:40:20AM -0700, Michael Thomas wrote: > >"Allowing unfiltered public access to port 25 is one of the things that > >increases everyone's spam load, and your ISP is trying to be a Good > >Neighbor in blocking access to anyone's servers but their own; many ISPs > >are moving towards this safer configuration. We're a good neighbor, as > >well, and support Mail Submission Protocol on port 587, and here's how > >you set it up -- and it will work from pretty much anywhere forever." > > I think this all vastly underrates the agility of the bad guys. So lots of > ISP's have blocked port 25. Has it made any appreciable difference? > Not that I can tell. If you block port 25, they'll just use another port and > a relay if necessary. You're forgetting that 587 *is authenticated, always*. The issue here, though, was that of an Enhanced Mail Provider's clients being unable to get through blocks *set by their client's ISPs*. The EMP has no control over that except to switch said clients to MSP (which they really should have done to begin with, as someone else notes). 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 alec.berry at restontech.com Wed Sep 3 11:57:51 2008 From: alec.berry at restontech.com (Alec Berry) Date: Wed, 03 Sep 2008 12:57:51 -0400 Subject: ingress SMTP In-Reply-To: <48BEBDF4.9040109@mtcc.com> References: <20080903151617.A14277808@relayer.avian.org> <48BEB3C3.1070600@gravityfree.com> <20080903161400.GI8979@cgi.jachomes.com> <48BEBDF4.9040109@mtcc.com> Message-ID: <48BEC20F.6040307@restontech.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Thomas wrote: > I think this all vastly underrates the agility of the bad guys. So > lots of ISP's have blocked port 25. Has it made any appreciable > difference? Not that I can tell. If you block port 25, they'll just > use another port and a relay if necessary. I'm pretty sure it has, although without aggregate stats from various ISPs it is hard to tell. Since mail transport is exclusively on port 25 (as opposed to mail submission), a bot cannot just hop to another port. > But the thing that's really pernicious about this sort of policy is > that it's a back door policy for ISP's to clamp down on all outgoing > ports in the name of "security". I don't think ISPs have anything to gain by randomly blocking ports. They may block a port that is often used for malicious behavior (135-139, 194, 445, 1433, 3306 come to mind) as a way to reduce their support calls-- but they would have to balance that with the risk of loosing customers. It's not as much a slippery slope as much as it is a tightrope act (yes-- I am metaphorically challenged). ... alec - -- `____________ / Alec Berry \______________________________ | Senior Partner and Director of Technology \ | PGP/GPG key 0xE8E9030F | | http://alec.restontech.com/#PGP | |-------------------------------------------| | RestonTech, Ltd. | | http://www.restontech.com/ | | Phone: (703) 234-2914 | \___________________________________________/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIvsINREO1P+jpAw8RAvKNAKC83NJgwv4EakAv/jw5biO79D/xEwCgldZ+ JHkb3LboeAD2GC77vcb06Y4= =nfVP -----END PGP SIGNATURE----- From ops.lists at gmail.com Wed Sep 3 12:06:16 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 3 Sep 2008 22:36:16 +0530 Subject: ingress SMTP In-Reply-To: <48BEBFEA.102@gravityfree.com> References: <20080903151617.A14277808@relayer.avian.org> <48BEB3C3.1070600@gravityfree.com> <48BEBFEA.102@gravityfree.com> Message-ID: On Wed, Sep 3, 2008 at 10:18 PM, Justin Scott wrote: >> Do you operate your mailserver on a residential cablemodem or adsl >> rather than a business account? > > No, we co-lo equipment at a professional facility that our customers on any > type of connection need to have access to send mail through, regardless of > whether their ISP blocks the standard ports or not. That's why you set your outbound MTA to listen - for auth'd outbound connections only - on port 587 Endless loop of dead horse beating .. ouch srs -- Suresh Ramasubramanian (ops.lists at gmail.com) From stephen at sprunk.org Wed Sep 3 12:07:22 2008 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 03 Sep 2008 12:07:22 -0500 Subject: ingress SMTP In-Reply-To: <48BEC20F.6040307@restontech.com> References: <20080903151617.A14277808@relayer.avian.org> <48BEB3C3.1070600@gravityfree.com> <20080903161400.GI8979@cgi.jachomes.com> <48BEBDF4.9040109@mtcc.com> <48BEC20F.6040307@restontech.com> Message-ID: <48BEC44A.5020506@sprunk.org> Alec Berry wrote: > Michael Thomas wrote: > >> But the thing that's really pernicious about this sort of policy is >> that it's a back door policy for ISP's to clamp down on all outgoing >> ports in the name of "security". >> > > I don't think ISPs have anything to gain by randomly blocking ports. They may block a port that is often used for malicious behavior (135-139, 194, 445, 1433, 3306 come to mind) as a way to reduce their support calls-- but they would have to balance that with the risk of loosing customers. It's not as much a slippery slope as much as it is a tightrope act (yes-- I am metaphorically challenged). > I see nothing wrong with filtering commonly abused ports, provided that the ISP allows a user to opt out if they know enough to ask. When port 25 block was first instituted, several providers actually redirected connections to their own servers (with spam filters and/or rate limits) rather than blocking the port entirely. This seems like a good compromise for port 25 in particular, provided you have the tools available to implement and support it properly. I also agree with the comments about switching customers to 587. My former monopoly ISP only accepted mail on 25 and I had endless problems trying to send mail from airports, hotels, coffee shops, etc. while traveling. The same hotspots also tended to block port 22, so I couldn't even forward mail via my own server. However, my new monopoly ISP only accepts mail on 587, and I have yet to have a single problem with that from any hotspot I've used since the switch. Ditto for reading my mail via IMAPS/993, whereas I used to have occasional problems reading it via IMAP/143. S From twinders at southplainscollege.edu Wed Sep 3 12:08:17 2008 From: twinders at southplainscollege.edu (Winders, Timothy A) Date: Wed, 03 Sep 2008 12:08:17 -0500 Subject: ingress SMTP In-Reply-To: Message-ID: On 9/3/08 10:50 AM, "Suresh Ramasubramanian" wrote: > On Wed, Sep 3, 2008 at 8:46 PM, *Hobbit* wrote: >> >> What I'm trying to get a feel for is this: what proportion of edge >> customers have a genuine NEED to send direct SMTP traffic to TCP 25 >> at arbitrary destinations? I'm thinking mostly of cable-modem and > > Not too many - they got themselves port 587 to submit outbound mail. > > Read the maawg managing port 25 document - and while you are at it > read the walled garden doc too.. port 25 abuse is the least of your > worries with cable/dsl cpe swamps > > http://www.maawg.org/port25 > http://www.maawg.org/about/whitepapers/MAAWG_Walled_Garden_BP_2007-09.pdf > > --srs > We have not setup a port 587 smtp submit server. Our smtp servers run only on port 25. We point our clients outbound email to these servers, which require authentication for relaying. We run into problems with ISPs and hotels which block outbound SMTP. They can't send email. We have to work with them to work with their ISPs to find out what SMTP server they can use for outgoing email. It's a big problem. Yes, setting up a 587 submit server internally would be best, but man power is at a premium and it hasn't happened. So, for us, having ISPs block port 25 is a problem. === Tim Tim Winders | Associate Dean of Information Technology | South Plains College From bmanning at vacation.karoshi.com Wed Sep 3 12:12:27 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 3 Sep 2008 17:12:27 +0000 Subject: 198.32.64.12 -- Harmless mis-route or potential exploit? In-Reply-To: <75cb24520809030700s63dba2a1xb7e54e7d3eb2c99@mail.gmail.com> References: <160A3E60-585D-4B34-88FE-8B09A8085893@virtualized.org> <20080903004049.GC1602@renesys.com> <75cb24520809021908h6114592dsfd2f2bb4be657235@mail.gmail.com> <20080903124830.GD18369@vacation.karoshi.com.> <75cb24520809030700s63dba2a1xb7e54e7d3eb2c99@mail.gmail.com> Message-ID: <20080903171227.GA21351@vacation.karoshi.com.> On Wed, Sep 03, 2008 at 10:00:41AM -0400, Christopher Morrow wrote: > On Wed, Sep 3, 2008 at 8:48 AM, wrote: > > On Tue, Sep 02, 2008 at 10:08:10PM -0400, Christopher Morrow wrote: > >> On 9/2/08, Todd Underwood wrote: > >> > >> > checking our current data, that block is not currently routed by any > >> > of our peers over the last month (i would assume ripe ris and > >> > routeviews report similar data, but i did not check them. > >> > >> it's also probably worth stating that parts of 198.32/16 are never > >> routed anywhere on the Internet (here comes bill to tell me 'who's > >> Internet?' .....). Some is in use on private networks, some is in use > >> at exchange points and not routed outside the immediate peers. > > > > grump... ok... "who's internet"? > > there he is!!! :) (thanks for restoring my faith in... humanity) WHO'S THAT TRIP-TRAPPING ACROSS MY BRIDGE? (random thought of the day ... is there a real requirement to do routing at the level of granularity we seem to have fallen into? is there any reason to not do more bridging, creating larger broadcast domains? Such constructs are certainly more ammenable to device mobility, esp in the absence of workable mobil IP and the derth of EID/LOC splits... and there would be less route churn.... lots of good reasons) > > > >> Most times, as I recall, epnet does a decent job of keeping the whois > >> data or rdns data updated though, for things in use. (though possibly > >> not for private uses) > > > > rdns moreso that whois... > > 198.32.64.12 == AS-20144-has-not-REGISTERED-the-use-of-this-prefix. > for instance? well that has been there for some time - we need not remove the clay-cap off that nuclear waste dump - let sleeping dogs lie. > > -chris --bill From simonw at zynet.net Wed Sep 3 12:24:38 2008 From: simonw at zynet.net (Simon Waters) Date: Wed, 3 Sep 2008 18:24:38 +0100 Subject: ingress SMTP In-Reply-To: <48BEC44A.5020506@sprunk.org> References: <20080903151617.A14277808@relayer.avian.org> <48BEC20F.6040307@restontech.com> <48BEC44A.5020506@sprunk.org> Message-ID: <200809031824.39036.simonw@zynet.net> On Wednesday 03 September 2008 18:07:22 Stephen Sprunk wrote: > > When port 25 block was first instituted, several providers actually > redirected connections to their own servers (with spam filters and/or > rate limits) rather than blocking the port entirely. This seems like a > good compromise for port 25 in particular, provided you have the tools > available to implement and support it properly. It generated some very confused support calls here, where folks said I sent email to your server, and we had to tell them "no you didn't, you only thought you did". Please if you are going to block it block it clearly and transparently. On the other hand abuse by bots isn't restricted to SMTP, and I suspect ISPs would be better of long term having a way of spotting compromised/malicious hosts and dealing with them, than applying a sticky plaster to port 25. Indeed spewing on port 25 is probably a good sign you need to apply said system. From nsuan at nonexiste.net Wed Sep 3 11:58:53 2008 From: nsuan at nonexiste.net (Nicholas Suan) Date: Wed, 3 Sep 2008 12:58:53 -0400 Subject: ingress SMTP In-Reply-To: <20080903164941.GL8979@cgi.jachomes.com> References: <20080903151617.A14277808@relayer.avian.org> <48BEB3C3.1070600@gravityfree.com> <20080903161400.GI8979@cgi.jachomes.com> <48BEBDF4.9040109@mtcc.com> <20080903164941.GL8979@cgi.jachomes.com> Message-ID: On Sep 3, 2008, at 12:49 PM, Jay R. Ashworth wrote: > On Wed, Sep 03, 2008 at 09:40:20AM -0700, Michael Thomas wrote: >>> "Allowing unfiltered public access to port 25 is one of the things >>> that >>> increases everyone's spam load, and your ISP is trying to be a Good >>> Neighbor in blocking access to anyone's servers but their own; >>> many ISPs >>> are moving towards this safer configuration. We're a good >>> neighbor, as >>> well, and support Mail Submission Protocol on port 587, and here's >>> how >>> you set it up -- and it will work from pretty much anywhere >>> forever." >> >> I think this all vastly underrates the agility of the bad guys. So >> lots of >> ISP's have blocked port 25. Has it made any appreciable difference? >> Not that I can tell. If you block port 25, they'll just use another >> port and >> a relay if necessary. > > You're forgetting that 587 *is authenticated, always*. > I'm not sure how that makes much of a difference since the usual spam vector is malware that has (almost) complete control of the machine in the first place. From Valdis.Kletnieks at vt.edu Wed Sep 3 12:26:54 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 03 Sep 2008 13:26:54 -0400 Subject: Is the export policy selective under valley-free? In-Reply-To: Your message of "Wed, 03 Sep 2008 10:36:52 +0200." References: <620fd17c0809021723w36693b2ctd3731a4bf706f5d9@mail.gmail.com> Message-ID: <22598.1220462814@turing-police.cc.vt.edu> On Wed, 03 Sep 2008 10:36:52 +0200, William Waites said: > Valley-free is a property of AS mesh models that says that, where edges > are classified as peering (p2p) or transit (c2p) that a valid path > contains zero or one peering link and that the peering link occurs > adjacent to the top of the path. That is that valid paths look like, > > [c2p c2p ... c2p p2p p2c ... p2c p2c] OK, I'm looking at this, and having a *little* trouble buying that there's exactly zero or one p2p links - consider the case where the last 'c2p' link is to provider A, who peers with B but not C, and B peers with both A and C, and the first p2c link lands at C. Don't you end up with "cp2 p2p p2p p2c" in that case? Or is there a convention saying we compress the A-B and B-C links into a notational A-C link? Or are we defining A-B or B-C links as being a c2p type instead, even though they're peering and not transit? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From Skywing at valhallalegends.com Wed Sep 3 12:28:47 2008 From: Skywing at valhallalegends.com (Skywing) Date: Wed, 3 Sep 2008 12:28:47 -0500 Subject: ingress SMTP Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6BD96B9FFEF@caralain.haven.nynaeve.net> Intercepting port 25 traffic of your customers (as an ISP), redirecting it to your own servers, and allowing the connection to complete sounds like a pretty slippery slope of badness to me. Sure, you should be using TLS anyway, but slurping up port 25 traffic begs the question of what is happening to the SMTP authentication credentials or the mail data that flows through said intercept. Blocking traffic versus intercepting it wholesale are very different ballgames. Now, obviously, whoever is providing your pipe has the technical ability to intercept your traffic. Actually doing this has proven widely unpopular (to place it nicely) when uncovered, even with the best of intentions. There is usually an implicit trust that your ISP won't be employing underhanded tactics like that in most people's minds, I think. I suspect that most people will call any interception of their outbound mail traffic "underhanded", even for if done for a perceived good reason in the mind of said ISP. - S -----Original Message----- From: Stephen Sprunk Sent: Wednesday, September 03, 2008 12:09 To: Alec Berry Cc: north American Noise and Off-topic Gripes Subject: Re: ingress SMTP Alec Berry wrote: > Michael Thomas wrote: > >> But the thing that's really pernicious about this sort of policy is >> that it's a back door policy for ISP's to clamp down on all outgoing >> ports in the name of "security". >> > > I don't think ISPs have anything to gain by randomly blocking ports. They may block a port that is often used for malicious behavior (135-139, 194, 445, 1433, 3306 come to mind) as a way to reduce their support calls-- but they would have to balance that with the risk of loosing customers. It's not as much a slippery slope as much as it is a tightrope act (yes-- I am metaphorically challenged). > I see nothing wrong with filtering commonly abused ports, provided that the ISP allows a user to opt out if they know enough to ask. When port 25 block was first instituted, several providers actually redirected connections to their own servers (with spam filters and/or rate limits) rather than blocking the port entirely. This seems like a good compromise for port 25 in particular, provided you have the tools available to implement and support it properly. I also agree with the comments about switching customers to 587. My former monopoly ISP only accepted mail on 25 and I had endless problems trying to send mail from airports, hotels, coffee shops, etc. while traveling. The same hotspots also tended to block port 22, so I couldn't even forward mail via my own server. However, my new monopoly ISP only accepts mail on 587, and I have yet to have a single problem with that from any hotspot I've used since the switch. Ditto for reading my mail via IMAPS/993, whereas I used to have occasional problems reading it via IMAP/143. S From bburke at merit.edu Wed Sep 3 12:41:10 2008 From: bburke at merit.edu (Betty Burke) Date: Wed, 3 Sep 2008 13:41:10 -0400 (EDT) Subject: [NANOG-announce] Important Reminders and Announcement In-Reply-To: <666919354.275691220463557246.JavaMail.root@crono> Message-ID: <205735381.275851220463670837.JavaMail.root@crono> Dear NANOG Community: Just a few reminders and a news item. The deadline for Steering Committee Nominations is near, Tue 2008-09-09. Complete election information is available on the NANOG website. The new process will work if many are involved... nudge: A great NANOG44 agenda is now posted. Make sure to check it out and register!! Merit, along with the entire NANOG community, appreciates the involvement and support from our sponsors. If you are interested, please send email to nanog-support at nanog.org, as a few sponsorship opportunities for NANOG44 remain. Do not miss out on your opportunity to be part of this meeting. As many of you know, Merit has been working to improve the NANOG.ORG website. We are very pleased to announce the new site will be launched on Thursday morning, Sept. 4, at 7 am EST. Members of the NANOG Steering Committee have been working with Merit, and we hope all issues have been resolved. We believe the community will find the new site to be much more useful. "I think the website looks great, is very professional, and a huge leap forward in functionality and usability", Philip Smith-SC Chair. New features include: - Graphic and Text version of the web site - New presentation archive that allows for searching by NANOG meeting, year, presenter and more. - "Print This" feature, which will strip away page navigation for easier printing. - Easier web site navigation and improved appearance - RSS Feeds and much more! The meeting archive and presentation archive are still being completed, but you will soon be able to access the remaining past meeting information. Thanks for being a part of NANOG. We hope you check out the new site and use it to keep in touch with important issues surrounding the Internet and the NANOG community. We look forward to seeing many of you in LA at NANOG44! and for your participation in the NANOG 2008 Elections process. As always, if you have any questions, concerns, or issues with NANOG support activities, please feel free to send a note to NANOG-Support at nanog.org or phone us at Merit (734)764-9430. All best. Betty Burke Merit/NANOG Project Manager www.nanog.org www.merit.edu _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From ww at styx.org Wed Sep 3 12:42:34 2008 From: ww at styx.org (William Waites) Date: Wed, 3 Sep 2008 19:42:34 +0200 Subject: Is the export policy selective under valley-free? In-Reply-To: <22598.1220462814@turing-police.cc.vt.edu> References: <620fd17c0809021723w36693b2ctd3731a4bf706f5d9@mail.gmail.com> <22598.1220462814@turing-police.cc.vt.edu> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 08-09-03 ? 19:26, Valdis.Kletnieks at vt.edu a ?crit : > > OK, I'm looking at this, and having a *little* trouble buying that > there's > exactly zero or one p2p links - consider the case where the last > 'c2p' link > is to provider A, who peers with B but not C, and B peers with both > A and C, > and the first p2c link lands at C. Don't you end up with "cp2 p2p > p2p p2c" in > that case? Or is there a convention saying we compress the A-B and > B-C > links into a notational A-C link? Or are we defining A-B or B-C > links as > being a c2p type instead, even though they're peering and not transit? If B passes along C's routes to A then that is not (in the model) a peering relationship. Only your own and your customers' routes get sent to peers not routes learned from other peers. So in this case B-C looks like p2c and A-B could be either p2p or c2p. Cases of partial transit, where B might repeat C's routes to peers but not to upstrem providers are not, AFAIK treated in the model. Cheers, - -w - -- William Waites http://www.irl.styx.org/ +49 30 8894 9942 CD70 0498 8AE4 36EA 1CD7 281C 427A 3F36 2130 E9F5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEUEARECAAYFAki+zIoACgkQQno/NiEw6fUxkwCeOf84XppppZk32YxxQdyiCNgW gggAlRe2Gg93sS+/HPgscj9+qiVwQ8c= =oBAp -----END PGP SIGNATURE----- From alec.berry at restontech.com Wed Sep 3 12:48:38 2008 From: alec.berry at restontech.com (Alec Berry) Date: Wed, 03 Sep 2008 13:48:38 -0400 Subject: ingress SMTP In-Reply-To: References: Message-ID: <48BECDF6.40005@restontech.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Winders, Timothy A wrote: > We have not setup a port 587 smtp submit server. Our smtp servers run only > on port 25. Sorry to be harsh, but that's just not the "right way to do things" these days. At the very least, you can run stunnel to allow incoming mail submission on port 465 (SMTP + SSL). > So, for us, having ISPs block port 25 is a problem. Read: "for us, running a mail server is a problem" ... alec - -- `____________ / Alec Berry \______________________________ | Senior Partner and Director of Technology \ | PGP/GPG key 0xE8E9030F | | http://alec.restontech.com/#PGP | |-------------------------------------------| | RestonTech, Ltd. | | http://www.restontech.com/ | | Phone: (703) 234-2914 | \___________________________________________/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIvs30REO1P+jpAw8RAtBUAJsFmxNfi9UGcDCfmkDs7Tni+iHuKwCgtKyg 01N7WA1sXhzuWsYD4ZG6go0= =66IU -----END PGP SIGNATURE----- From twinders at southplainscollege.edu Wed Sep 3 12:53:26 2008 From: twinders at southplainscollege.edu (Winders, Timothy A) Date: Wed, 03 Sep 2008 12:53:26 -0500 Subject: ingress SMTP In-Reply-To: <48BECDF6.40005@restontech.com> Message-ID: On 9/3/08 12:48 PM, "Alec Berry" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Winders, Timothy A wrote: > >> We have not setup a port 587 smtp submit server. Our smtp servers run only >> on port 25. > > Sorry to be harsh, but that's just not the "right way to do things" > these days. At the very least, you can run stunnel to allow incoming > mail submission on port 465 (SMTP + SSL). > >> So, for us, having ISPs block port 25 is a problem. > > Read: "for us, running a mail server is a problem" Not harsh at all. It's reality. We do have the option for SMTP/SSL/TLS over port 25. It is only required for an authenticated session. I agree, it's not the "right way to do things". Running a mail server used to be much easier. Volunteers to help set things up "the right way" are always welcome. :-) Otherwise, it will happen "eventually". :-( Tim Winders | Associate Dean of Information Technology | South Plains College From jfesler at gigo.com Wed Sep 3 12:59:51 2008 From: jfesler at gigo.com (Jason Fesler) Date: Wed, 3 Sep 2008 10:59:51 -0700 (PDT) Subject: ingress SMTP In-Reply-To: References: Message-ID: > I agree, it's not the "right way to do things". Running a mail server used > to be much easier. Volunteers to help set things up "the right way" are > always welcome. :-) Supporting those clients who can't connect is cheaper or more accessible for you? From twinders at southplainscollege.edu Wed Sep 3 13:04:33 2008 From: twinders at southplainscollege.edu (Winders, Timothy A) Date: Wed, 03 Sep 2008 13:04:33 -0500 Subject: ingress SMTP In-Reply-To: Message-ID: On 9/3/08 12:59 PM, "Jason Fesler" wrote: >> I agree, it's not the "right way to do things". Running a mail server used >> to be much easier. Volunteers to help set things up "the right way" are >> always welcome. :-) > > Supporting those clients who can't connect is cheaper or more accessible > for you? > At this point, yes. We offer SSL/VPN connections back into the network which (so far) has always fixed the problem if the client is unable to work with their ISP to get smtp settings for their email program. It's a matter of resources and priorities. I'd also like to setup an automated provisioning server, but don't know how to do that. There are many projects "in the wings". Registering students and making sure they can pay for classes always seems to bubble to the top, though. ;-) Of course, this is getting a bit off topic for NANOG, so I'll stop there. Tim Winders | Associate Dean of Information Technology | South Plains College From dot at dotat.at Wed Sep 3 13:06:28 2008 From: dot at dotat.at (Tony Finch) Date: Wed, 3 Sep 2008 19:06:28 +0100 Subject: ingress SMTP In-Reply-To: <48BECDF6.40005@restontech.com> References: <48BECDF6.40005@restontech.com> Message-ID: On Wed, 3 Sep 2008, Alec Berry wrote: > > At the very least, you can run stunnel to allow incoming > mail submission on port 465 (SMTP + SSL). I would be very very careful with that kind of setup. Connections to port 25 from localhost (even if they are from stunnel running on localhost) often bypass most or all of the MTA's security checks. Tony. -- f.anthony.n.finch http://dotat.at/ FAIR ISLE: CYCLONIC 4 OR 5, BUT 6 OR 7 IN NORTHWEST. MODERATE OR ROUGH. SHOWERS. MODERATE OR GOOD. From hobbit at avian.org Wed Sep 3 12:15:41 2008 From: hobbit at avian.org (*Hobbit*) Date: Wed, 3 Sep 2008 17:15:41 +0000 (GMT) Subject: ingress SMTP Message-ID: <20080903171541.B7E547808@relayer.avian.org> Wow, lots of responses already. Thanks, good discussion. I should clarify a little, that it's not necessarily about "blanket" port blocking or denying "random" ports as threats are perceived, but where needed in a well thought-out manner and trying to take customer needs [stated or observed] into account first. And back it up with AUP verbiage. There must be plenty of places where it just makes sense, and others where it's borderline, iffy, or unmanageable. One has to start *someplace*. Oh, and don't get me started about abuse-desk competency, or even existence, especially in the big providers. I'll bet most of them can't even find the *rack* where the autoresponder machine is, let alone actually figure out why its disk has been full for six months. Related question, now that some discussion has started: why the F does Gmail refuse to put real, identifiable injection-path headers in mail they relay out? The current "policy" only protects spammer identities behind a meaningless 10.x and is completely at odds with what almost every other freemail provider does, which of course breaks any receiving-end model. Who's here from Google that I can chat with about this? _H* From schampeo at hesketh.com Wed Sep 3 13:20:12 2008 From: schampeo at hesketh.com (Steven Champeon) Date: Wed, 3 Sep 2008 14:20:12 -0400 Subject: ingress SMTP In-Reply-To: <20080903171541.B7E547808@relayer.avian.org> References: <20080903171541.B7E547808@relayer.avian.org> Message-ID: <20080903182012.GB10846@hesketh.com> on Wed, Sep 03, 2008 at 05:15:41PM +0000, *Hobbit* wrote: > Related question, now that some discussion has started: why the F > does Gmail refuse to put real, identifiable injection-path headers > in mail they relay out? The current "policy" only protects spammer > identities behind a meaningless 10.x and is completely at odds with > what almost every other freemail provider does, which of course > breaks any receiving-end model. Who's here from Google that I can > chat with about this? Dunno who's here from Google, but every time I've asked about this (as the basis for a discussion of why they do such a sucky job of blocking 419 scams, which we otherwise block by injection point analysis) I've been told that it's a "privacy" issue. I long suspected it was just a side effect of an inflexible network architecture, but have been assured that, no, it's the privacy issue. And yes, this is completely at odds with the fact that they *do* put injection point IP audit trail into mail they relay via SMTP. In the end, it's an idiotic policy, and I hope they wake up and fix it. In the meantime, I'm reporting every 419 scam I get from them. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)747-9073 w: http://hesketh.com/ antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/ From jra at baylink.com Wed Sep 3 14:00:15 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Wed, 3 Sep 2008 15:00:15 -0400 Subject: ingress SMTP In-Reply-To: References: <20080903151617.A14277808@relayer.avian.org> <48BEB3C3.1070600@gravityfree.com> <20080903161400.GI8979@cgi.jachomes.com> <48BEBDF4.9040109@mtcc.com> <20080903164941.GL8979@cgi.jachomes.com> Message-ID: <20080903190015.GS8979@cgi.jachomes.com> On Wed, Sep 03, 2008 at 12:58:53PM -0400, Nicholas Suan wrote: > On Sep 3, 2008, at 12:49 PM, Jay R. Ashworth wrote: > >You're forgetting that 587 *is authenticated, always*. > > I'm not sure how that makes much of a difference since the usual spam > vector is malware that has (almost) complete control of the machine > in the first place. Well, that depends on MUA design, of course, but it's just been pointed out to me that the RFC says MAY, not MUST. Oops. Does anyone bother to run an MSA on 587 and *not* require authentication? 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 twinders at southplainscollege.edu Wed Sep 3 14:32:55 2008 From: twinders at southplainscollege.edu (Winders, Timothy A) Date: Wed, 03 Sep 2008 14:32:55 -0500 Subject: ingress SMTP In-Reply-To: Message-ID: On 9/3/08 1:04 PM, "Winders, Timothy A" wrote: > On 9/3/08 12:59 PM, "Jason Fesler" wrote: > >>> I agree, it's not the "right way to do things". Running a mail server used >>> to be much easier. Volunteers to help set things up "the right way" are >>> always welcome. :-) >> >> Supporting those clients who can't connect is cheaper or more accessible >> for you? >> > > At this point, yes. We offer SSL/VPN connections back into the network which > (so far) has always fixed the problem if the client is unable to work with > their ISP to get smtp settings for their email program. > > It's a matter of resources and priorities. I'd also like to setup an > automated provisioning server, but don't know how to do that. > > There are many projects "in the wings". Registering students and making sure > they can pay for classes always seems to bubble to the top, though. ;-) > > Of course, this is getting a bit off topic for NANOG, so I'll stop there. > > Tim Winders | Associate Dean of Information Technology | South Plains College This thread has inspired me to get off my duff and "get it done". I now have a properly working MSA running on port 587 requiring authentication. A few updates to user documentation and we'll be setup and running. Thanks for the kick in the pants. :-) Tim Winders | Associate Dean of Information Technology | South Plains College From randy at psg.com Wed Sep 3 14:49:20 2008 From: randy at psg.com (Randy Bush) Date: Thu, 04 Sep 2008 07:49:20 +1200 Subject: Is the export policy selective under valley-free? In-Reply-To: <63720188-557D-4FDA-8C65-64181D66B2B3@styx.org> References: <4EF4ADA5-960A-4B5E-8D56-A364E543046F@muada.com> <118AB17C-DEA7-49AA-9E1C-E51798DAE326@styx.org> <48BE5B90.6040008@psg.com> <63720188-557D-4FDA-8C65-64181D66B2B3@styx.org> Message-ID: <48BEEA40.3080409@psg.com> >> i assure you that the actual topology is not valley free. e.g. there >> are many backup or political hack transit paths [0] > Sorry to further impinge on your vacation, but was there a footnote there? apologies. one publicly known (because someone used traceroute) example is mentioned in and likely more widely discussed around that time. usually such arrangements, peering and transit (occasionally bi-dir selective transit) mixed. expect to see more next year when the court restrictions have expired and the other randy releases his pent up anger/greed :) randy From randy at psg.com Wed Sep 3 15:38:35 2008 From: randy at psg.com (Randy Bush) Date: Thu, 04 Sep 2008 08:38:35 +1200 Subject: hosting net guest Message-ID: <48BEF5CB.5060404@psg.com> we have a couple of sharp net engs coming to nanog/arin in la from far less privileged parts of the world. i thought it might be nice if they could stay a few extra days or a week to see how those of us privileged to have larger markets and hence scaled up networks run our shows. would anyone on the left coast be willing to host a guest or two for a few days and let them see inside the guts of your operation? responses to me privately, please. and excuse poor response this week as i am on holiday. thanks. randy From Valdis.Kletnieks at vt.edu Wed Sep 3 15:51:53 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 03 Sep 2008 16:51:53 -0400 Subject: ingress SMTP In-Reply-To: Your message of "Wed, 03 Sep 2008 15:00:15 EDT." <20080903190015.GS8979@cgi.jachomes.com> References: <20080903151617.A14277808@relayer.avian.org> <48BEB3C3.1070600@gravityfree.com> <20080903161400.GI8979@cgi.jachomes.com> <48BEBDF4.9040109@mtcc.com> <20080903164941.GL8979@cgi.jachomes.com> <20080903190015.GS8979@cgi.jachomes.com> Message-ID: <32732.1220475113@turing-police.cc.vt.edu> On Wed, 03 Sep 2008 15:00:15 EDT, "Jay R. Ashworth" said: > Does anyone bother to run an MSA on 587 and *not* require authentication? Presumably only sites that don't care if they end up in half the anti-spam blacklists on the planet. Based on the evidence I have, there's a depressingly large number of those sort of sites.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Wed Sep 3 16:08:50 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 03 Sep 2008 17:08:50 -0400 Subject: Is the export policy selective under valley-free? In-Reply-To: Your message of "Wed, 03 Sep 2008 19:42:34 +0200." References: <620fd17c0809021723w36693b2ctd3731a4bf706f5d9@mail.gmail.com> <22598.1220462814@turing-police.cc.vt.edu> Message-ID: <33545.1220476130@turing-police.cc.vt.edu> On Wed, 03 Sep 2008 19:42:34 +0200, William Waites said: > Cases of partial transit, where B might repeat C's routes to peers but not > to upstrem providers are not, AFAIK treated in the model. Ahh... that's the part I was missing. Thanks... (All the scenarios I though of were basically different partial transits...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From iljitsch at muada.com Wed Sep 3 16:22:13 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 3 Sep 2008 23:22:13 +0200 Subject: Is the export policy selective under valley-free? In-Reply-To: <33545.1220476130@turing-police.cc.vt.edu> References: <620fd17c0809021723w36693b2ctd3731a4bf706f5d9@mail.gmail.com> <22598.1220462814@turing-police.cc.vt.edu> <33545.1220476130@turing-police.cc.vt.edu> Message-ID: <13E2F977-A78E-4C0F-8798-DF87F9A192AF@muada.com> On 3 sep 2008, at 23:08, Valdis.Kletnieks at vt.edu wrote: >> Cases of partial transit, where B might repeat C's routes to peers >> but not >> to upstrem providers are not, AFAIK treated in the model. > Ahh... that's the part I was missing. Thanks... (All the scenarios > I though > of were basically different partial transits...) Well, _not_ announcing stuff as a rule doesn't break BGP convergence so don't worry about it. :-) (These Gao and Rexford guys are on to something... I ran their example non-valley-free topology and it was still converging after 15000 iterations.) From charles at thewybles.com Wed Sep 3 15:58:21 2008 From: charles at thewybles.com (Charles Wyble) Date: Wed, 03 Sep 2008 13:58:21 -0700 Subject: ingress SMTP In-Reply-To: <20080903151617.A14277808@relayer.avian.org> References: <20080903151617.A14277808@relayer.avian.org> Message-ID: <48BEFA6D.6070507@thewybles.com> *Hobbit* wrote: > What I'm trying to get a feel for is this: what proportion of edge > customers have a genuine NEED to send direct SMTP traffic to TCP 25 > at arbitrary destinations? Probably very few. > > The big providers -- comcast, verizon, RR, charter, bellsouth, etc -- > seem to be some of the most significant sources of spam and malware > attempts, mostly from compromised end-user machines, and it seems > that simply denying *INGRESS* of TCP 25 traffic except to the given > ISP's outbound relay servers would cut an awful lot of it off at the > pass. I have SBC / AT&T / Yahoo DSL in Southern California and they block outbound 25 to anything but Yahoo SMTP server farm, and they only allow SSL connectivity at that. I'm all for that personally. It was a minor effort to setup my charles at thewybles.com address to be allowed out (had to fill out a webform and click a verify link). Since most people use the address given to them by the provider and most likely use webmail this certainly won't affect them. To top it all off I can fill out another web form and specifically request unblocking of ports and relay out mail server wherever I want. So SBC has a policy of deny SMTP relaying by default, provide clear instructions to allow outbound relay via approved server farm if you don't want to be blocked request unblocking via a self service web form. Seems perfectly acceptable to me. Thoughts? -- Charles Wyble (818) 280 - 7059 http://charlesnw.blogspot.com CTO Known Element Enterprises / SoCal WiFI project From lowen at pari.edu Wed Sep 3 16:29:19 2008 From: lowen at pari.edu (Lamar Owen) Date: Wed, 3 Sep 2008 17:29:19 -0400 Subject: self-promotion [was: 198.32.64.12 -- Harmless mis-route or In-Reply-To: <20080903092412.3aa8af5d@yellowstone.machshav.com> References: <20080902215018.07cfef0d@cs.columbia.edu> Message-ID: <200809031729.19865.lowen@pari.edu> On Wednesday 03 September 2008 09:24:12 Steven M. Bellovin wrote: > It's in the interest of brevity... > > --Steve Bellovin, http://www.cs.columbia.edu/~smb Two tabs and double dashes is shorter than double-dashes and newline? From frnkblk at iname.com Wed Sep 3 16:36:10 2008 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 3 Sep 2008 16:36:10 -0500 Subject: ingress SMTP In-Reply-To: <48BEB3C3.1070600@gravityfree.com> References: <20080903151617.A14277808@relayer.avian.org> <48BEB3C3.1070600@gravityfree.com> Message-ID: I would like to point my customers to port 587, but that kind of configuration is still in its infancy. We ask our employees of our business customers to VPN into work and for everyone else to use our webmail. Frank -----Original Message----- From: Justin Scott [mailto:jscott at gravityfree.com] Sent: Wednesday, September 03, 2008 10:57 AM To: nanog at nanog.org Subject: Re: ingress SMTP > What is preventing this from being an operational no-brainer, > including making a few exceptions for customers that prove they know > how to lock down their own mail infrastructure? As a small player who operates a mail server used by many local businesses, this becomes a support issue for admins in our position. We operate an SMTP server of our own that the employees of these various companies use from work and at home. Everything works great until an ISP decides to block 25 outbound. Now our customer cannot reach our server, so they call us to complain that they can receive but not send e-mail. We, being somewhat intelligent, have a support process in place to walk the customer through the SMTP port change from 25 to one of our two alternate ports. The problem, however, is that the customer simply cannot understand why their e-mail worked one day and doesn't the next. In their eyes the system used to work, and now it doesn't, so that must mean that we broke it and that we don't know what we're doing. Your comment about "exceptions for customers that prove they know how to lock down" is not based in reality, frankly. Have you ever tried to have Joe Sixpack call BigISP support to ask for an exception to a port block on his consumer-class connection with a dynamic IP? That's a wall that I would not be willing to ask my customers to climb over. Now, having said all that, I do agree that big ISPs should do more to prevent spam from originating at their networks. A basic block of 25 isn't the solution, in my opinion. Unfortunately I don't know what is. Perhaps monitoring the number of outgoing connections on 25 and temporarily cutting off access if a threshold is reached? Set it high enough and the legitimate users won't notice, but low enough that it disrupts the spammers. Perhaps I'm talking out of my ass and don't have a clue. In any case, I don't believe a blanket block of 25 is the answer. -Justin Scott, GravityFree From frnkblk at iname.com Wed Sep 3 16:38:13 2008 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 3 Sep 2008 16:38:13 -0500 Subject: ingress SMTP In-Reply-To: <20080903160644.GH8979@cgi.jachomes.com> References: <20080903151617.A14277808@relayer.avian.org> <20080903160644.GH8979@cgi.jachomes.com> Message-ID: Mediacom appears to require SSL to POP3 access: http://www.mchsi.com/help/read/publisher_02/2002-01-28.01 "If you are off the Mediacom Online network you can still access your e-mail using your e-mail client. However, you will need to configure your e-mail program to connect to our secure e-mail server via SSL." Frank -----Original Message----- From: Jay R. Ashworth [mailto:jra at baylink.com] Sent: Wednesday, September 03, 2008 11:07 AM To: nanog at nanog.org Subject: Re: ingress SMTP On Wed, Sep 03, 2008 at 11:52:48AM -0400, Tim Sanderson wrote: > Anybody not wanting to use their ISP email would notice it. I see > filtering 25 FROM the customer as something that is not likely to > happen because of this. When a customer buys bandwidth, they want to > be able to use it for whatever they choose. This would be just one > more restriction giving competitive advantage to any ISP not doing the > filtering. Just as long as consumer ISPs don't start filtering *110* inbound from the net... as AT&T used to. I had a client move from dialup to cablemodem about 10 years ago... and it took us a *week* to get AT&T to admit they didn't accept inbound POP pickups. Client (intemperately) had printed the att.com email address of lots of crap -- they had to keep the dialup for a long time, since at&t wouldn't forward either... Thank ghod I'm out of the jungle 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 bonomi at mail.r-bonomi.com Wed Sep 3 16:41:18 2008 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Wed, 3 Sep 2008 16:41:18 -0500 (CDT) Subject: ingress SMTP Message-ID: <200809032141.m83LfIf4009727@mail.r-bonomi.com> > From nanog-bounces at nanog.org Wed Sep 3 11:58:37 2008 > From: Alec Berry > Subject: Re: ingress SMTP > > Michael Thomas wrote: > > I think this all vastly underrates the agility of the bad guys. So > > lots of ISP's have blocked port 25. Has it made any appreciable > > difference? Not that I can tell. If you block port 25, they'll just > > use another port and a relay if necessary. > > I'm pretty sure it has, although without aggregate stats from various > ISPs it is hard to tell. Since mail transport is exclusively on port 25 > (as opposed to mail submission), a bot cannot just hop to another port. One small data-point -- on a personal vanity domain, approximately 2/3 of all the spam (circa 15k junk emails/month) was 'direct to inbound MX' transmissions. The vast majority of this is coming from end-user machines outside of North America. China, India Thailand, Brazil, Poland, "CZ", and a couple of providers each in Germany and France, appear to be the most prevalent sources _I_ see. The message count would be a fair bit higher, but I have several overseas networks (4 in DE, 2 in TW, 1 in CZ) plus pieces of 2 domestic networks (*da.uu.net, *pub-ip.psi.net) blocked at the firewall. Also firewalled are a couple of dozen IP addresses that have -each- made over 10k attempts to _relay_ mail through me. I'm seeing a significant amount of 'Received' header forgery, apparently intended to fool "dumb" header parsers into believing the direct-to-MX transmission _did_ go through the server associated with the domain used in the '"from: ", "from ", and "Reply-to: " lines. The good news is that only a _really_ dumb parser would be fooled by most of what I'm seeing. :) From cboyd at gizmopartners.com Wed Sep 3 16:53:28 2008 From: cboyd at gizmopartners.com (Chris Boyd) Date: Wed, 3 Sep 2008 16:53:28 -0500 Subject: ingress SMTP In-Reply-To: References: <20080903151617.A14277808@relayer.avian.org> <48BEB3C3.1070600@gravityfree.com> Message-ID: On Sep 3, 2008, at 4:36 PM, Frank Bulk wrote: > I would like to point my customers to port 587, but that kind of > configuration is still in its infancy. We're a small managed services provider, and we started doing authenticated SMTP with TLS on port 587 six years ago. It's at least in kindergarten :-) Once we explain the advantages, our customers love it since their email "just works" pretty much wherever they go. As a former manager for a small resnet, blocking port 25 outbound is A Good Thing. Cut abuse email down by a huge factor. --Chris From dts at senie.com Wed Sep 3 16:52:18 2008 From: dts at senie.com (Daniel Senie) Date: Wed, 03 Sep 2008 17:52:18 -0400 Subject: ingress SMTP In-Reply-To: <48BEBFEA.102@gravityfree.com> References: <20080903151617.A14277808@relayer.avian.org> <48BEB3C3.1070600@gravityfree.com> <48BEBFEA.102@gravityfree.com> Message-ID: <200809032157.m83Lvhdu017995@parsley.amaranth.net> At 12:48 PM 9/3/2008, you wrote: >>Do you operate your mailserver on a residential cablemodem or adsl >>rather than a business account? > >No, we co-lo equipment at a professional facility that our customers >on any type of connection need to have access to send mail through, >regardless of whether their ISP blocks the standard ports or not. > > >-Justin Scott, GravityFree > I've been running a similar operation for over a decade, offering email services, web services and collocation to businesses from the tiny to the multinational. We have, since the beginning, provided instructions on using port 587 and port 465 for email submission. This is not hard to explain, and it has never been a problem for our customers or their tech folks to accomplish. Our servers are in data centers, our customers are on DSL, cable or even dialup circuits. We assume port 25 will be blocked, and while it isn't always, starting with that assumption simplifies matters. We also encourage our customers to always use TLS or SSL for all exchanges with the mail servers. Because we have many users who are road warriors, they never know who their local access ISP will be. Getting them set up for 587 or 465 before they leave home has always kept folks out of trouble. And those few who don't heed our advice have had their email hijacked by hotel networks that consume traffic to any remote port 25 themselves in an attempt to "help." So again, just get your customers configured right at the start, and there will be few support calls on the subject. This is just part of being a third-party supplier of email services in the current reality. Dan From matthew at sorbs.net Wed Sep 3 17:53:15 2008 From: matthew at sorbs.net (matthew at sorbs.net) Date: Thu, 04 Sep 2008 08:53:15 +1000 Subject: ingress SMTP Message-ID: Justin Scott said: > > Your comment about "exceptions for customers that prove they know how to > lock down" is not based in reality, frankly. Have you ever tried to > have Joe Sixpack call BigISP support to ask for an exception to a port > block on his consumer-class connection with a dynamic IP? That's a wall > that I would not be willing to ask my customers to climb over. iiNet a reasonably sized Aussie ISP has a web page (specifially part of the 'My Account' page) where you can, with a simple check box, choose to have commonly abused ports blocked *for outgoing connections* or not. Last time I looked the ports blocked were: Port 25 Port 137 Port 138 Port 139 Port 445 How the back end works I don't know, but it is pretty seemless to the user, as I opted out of the block as soon as I connected. Their tech support is reasonably unintelligent at level 1, but even they were able to understand my problem and explain where the checkbox was so that within 35 seconds of taking the call my servers were open to the Internet in both directions. Regards, Matthew From matthew at sorbs.net Wed Sep 3 18:04:36 2008 From: matthew at sorbs.net (matthew at sorbs.net) Date: Thu, 04 Sep 2008 09:04:36 +1000 Subject: ingress SMTP Message-ID: <37a52d2a.2d2a37a5@sorbs.net> ----- Original Message ----- From: "Jay R. Ashworth" Date: Thursday, September 4, 2008 5:00 am Subject: Re: ingress SMTP > > Does anyone bother to run an MSA on 587 and *not* require > authentication? Many can be configured that way (example: Sun One/iPlanet mail server can). Whether they are or not depends on the admin. / M From mike at mtcc.com Tue Sep 2 18:42:48 2008 From: mike at mtcc.com (Michael Thomas) Date: Tue, 02 Sep 2008 16:42:48 -0700 Subject: Why not go after bots? (was: ingress SMTP) In-Reply-To: <48BEFA6D.6070507@thewybles.com> References: <20080903151617.A14277808@relayer.avian.org> <48BEFA6D.6070507@thewybles.com> Message-ID: <48BDCF78.8080009@mtcc.com> Charles Wyble wrote: > > I have SBC / AT&T / Yahoo DSL in Southern California and they block > outbound 25 to anything but Yahoo SMTP server farm, and they only > allow SSL > connectivity at that. I'm all for that personally. That seems to be the convention wisdom, but the science experiment as it were in blocking port 25 doesn't seem to be correlated (must less causated) with any drop in the spam rate. Because so far as I've heard there isn't any such drop. Spammers and the rest are pretty resourceful. So I still haven't heard why there isn't any emphasis on going after the bots that are by far the biggest problem instead of erecting damage for them to route around. I can sort of understand why providers are leery of getting sucked into that battle, but it's got to cost them a fortune for every "My internet is slow" call they take. Mike From charles at thewybles.com Wed Sep 3 19:04:21 2008 From: charles at thewybles.com (Charles Wyble) Date: Wed, 03 Sep 2008 17:04:21 -0700 Subject: Why not go after bots? In-Reply-To: <48BDCF78.8080009@mtcc.com> References: <20080903151617.A14277808@relayer.avian.org> <48BEFA6D.6070507@thewybles.com> <48BDCF78.8080009@mtcc.com> Message-ID: <48BF2605.4070304@thewybles.com> Michael Thomas wrote: > Charles Wyble wrote: >> >> I have SBC / AT&T / Yahoo DSL in Southern California and they block >> outbound 25 to anything but Yahoo SMTP server farm, and they only >> allow SSL >> connectivity at that. I'm all for that personally. > That seems to be the convention wisdom, but the science experiment > as it were in blocking port 25 doesn't seem to be correlated (must > less causated) with any drop in the spam rate. Because so far as I've > heard there isn't any such drop. Spammers and the rest are pretty > resourceful. Well.... SBC in SoCal is one of many providers. I think a lot of spam comes from outside of the united states end user subscriber pools as well. :) > > So I still haven't heard why there isn't any emphasis on going after > the bots that are by far the biggest problem instead of erecting damage > for them to route around. Well there are plenty of security lists / blogs / forums etc where much effort is being put forth towards eliminating the bots. > I can sort of understand why providers are > leery of getting sucked into that battle, but it's got to cost them a > fortune for every "My internet is slow" call they take. > > Mike > -- Charles Wyble (818) 280 - 7059 http://charlesnw.blogspot.com CTO Known Element Enterprises / SoCal WiFI project From jrhett at netconsonance.com Wed Sep 3 19:22:55 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Wed, 3 Sep 2008 17:22:55 -0700 Subject: Force10 Gear - Opinions In-Reply-To: <00c401c9072b$f46a38c0$dd3eaa40$@com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <00c401c9072b$f46a38c0$dd3eaa40$@com> Message-ID: On Aug 25, 2008, at 8:29 PM, James Jun wrote: >>> As a box designed with the enterprise datacenter in mind, the E- >> series >>> looks to be missing several key service provider features, including >>> MPLS and advanced control plane filtering/policing. >> >> >> Ah, because Cisco does either of these in hardware? > > Yes. PFC3 inside Supervisor 32, 720 and RSP 720 for Catalyst 6500/ > Router > 7600 series perform both of these features in hardware. The article > mentioned in this thread compares Force10 E against the 6500 series. Sorry, I was on an installation with 6500s and 720s trying to do uRPF and it kept falling back to software and killing the units. What your reading has no reality in my experience. I've been told exactly the same about MPLS by someone I trust (and who would only speak based on real experience, not reading online articles) "It works kindof, but when it fails you lose the entire network". -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Wed Sep 3 19:28:29 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Wed, 3 Sep 2008 17:28:29 -0700 Subject: Force10 Gear - Opinions In-Reply-To: <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> Message-ID: <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> On Aug 26, 2008, at 12:18 AM, Paul Wall wrote: >> They appear to be nonsense. They were bought and paid >> for by Cisco, and including nonsense things like "if you leave a >> slot open >> the chassis will burn up" as a decrement, which is also true in >> pretty much >> every big iron vendor. > > Current-generation Cisco and Juniper hardware don't seem to have > this problem. Your statement doesn't match my experience. > I don't think the "remove one SFM and all the others go offline" > failure mode is commonplace among other vendors either. It is neither common nor even actual on Force10. I've pulled many an SFM ;-) >> They also deliberately detuned the force10 >> configuration. They re-ran the tests using the recommended >> configuration >> and got very different numbers -- which you can request from them, >> but they >> won't publish on the website. > > I'd be interested in seeing this. Mind putting them up somewhere and > sharing the URL? Sorry, my day job doesn't include promoting anyone's gear or etc. Got other things need doing. Ask EATC and ask them about their ethics while you're at it. >> Based on what? For E and C series boxes, Cisco is never cheaper. >> S-series >> are a different story. > > I was comparing list pricing for the E-series up against Catalyst > 6500, Supervisor 720-3BXL, 6700 blades with CFC... which I consider a > fair comparison. For equivalent redundancy and ports, the Force10 is always cheaper - even just in list price. (on the E-series -- Cisco has some cheaper options than the S-series so I've heard - don't care) >>> As a box designed with the enterprise datacenter in mind, the E- >>> series >>> looks to be missing several key service provider features, including >>> MPLS and advanced control plane filtering/policing. >> >> Ah, because Cisco does either of these in hardware? > > Yes, they do, on the s720-3B and better. No, they don't. There are *no* *zero* providers doing line-speed uRPF on Cisco for a reason. Stop reading, start testing. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Wed Sep 3 19:29:52 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Wed, 3 Sep 2008 17:29:52 -0700 Subject: Force10 Gear - Opinions In-Reply-To: <620fd17c0808260026g1b1b7e97u64f7b3778e52ea4f@mail.gmail.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808260026g1b1b7e97u64f7b3778e52ea4f@mail.gmail.com> Message-ID: <1AE55697-DD7B-4721-8FC1-610524A283B8@netconsonance.com> On Aug 26, 2008, at 12:26 AM, Paul Wall wrote: > Routing n*GE at line rate isn't difficult these days, even with all > 64-byte packets and other "DoS" conditions. > > Linksys, D-Link, SMC, etc are able to pull it off on the layer 3 > switches sold at Fry's for a couple benjamins a pop. :) Sorry, I thought you were serious. I didn't realize you were joking. Carry on. *plonk* -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From james at towardex.com Wed Sep 3 19:30:28 2008 From: james at towardex.com (James Jun) Date: Wed, 3 Sep 2008 20:30:28 -0400 Subject: Force10 Gear - Opinions In-Reply-To: References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <00c401c9072b$f46a38c0$dd3eaa40$@com> Message-ID: <007401c90e25$6eaf2280$4c0d6780$@com> > > > > Yes. PFC3 inside Supervisor 32, 720 and RSP 720 for Catalyst 6500/ > > Router > > 7600 series perform both of these features in hardware. The article > > mentioned in this thread compares Force10 E against the 6500 series. > > > Sorry, I was on an installation with 6500s and 720s trying to do uRPF > and it kept falling back to software and killing the units. What your > reading has no reality in my experience. uRPF was problematic back in PFC2 based platforms (i.e. SUP2) where it is further dependent upon unicast routes in FIB TCAM. uRPF currently works fine enough on PFC3 based sups, the only problem however is currently only "one or the other" mode is supported for the entire box, as opposed to per interface. For example, configuring loose-mode uRPF in one interface, then configuring a strict-mode in another will result in entire box behaving as strict-mode interface for all uRPF enabled interfaces. Other than this caveat, I never had problems with it. However, these uRPF issues are fully documented. Reading manuals and documentation should help you avoid getting into operational problems such as "kept falling back and killing the units" scenario. Control plane policing via cp-policer works quite well on pfc3 based 6500's. This is ofcourse a very important feature (more important than uRPF in today's internet IMO) that appears to be missing in f10 gear which is what Paul was saying earlier. james From jrhett at netconsonance.com Wed Sep 3 19:32:02 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Wed, 3 Sep 2008 17:32:02 -0700 Subject: Force10 Gear - Opinions In-Reply-To: References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <48B41978.9040201@sprunk.org> Message-ID: On Aug 26, 2008, at 9:46 AM, Owen DeLong wrote: > Bottom line, in a few years, everyone carrying full tables with F10 > gear will probably need to > upgrade all of their line cards to quad-cam. Why is this statement being limited to F10? It appears to be true of every vendor. But why quad-cam? The dual-cam cards have indecent amounts of storage. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Wed Sep 3 19:32:56 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Wed, 3 Sep 2008 17:32:56 -0700 Subject: Force10 Gear - Opinions In-Reply-To: References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <48B41978.9040201@sprunk.org> Message-ID: On Aug 31, 2008, at 11:19 PM, Greg VILLAIN wrote: > What I also used to dislike is the lack of verbosity of 'show > features' - but that was back a year ago. Much improved in the last 2 years. > Btw, you absolutely want to avoid the S series, the CLI is a pain, > and is not the same as the E or C series, and lacks many features. The old HP-CLI they used is gone, it's a full FTOS now. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From kmedcalf at dessus.com Wed Sep 3 19:34:12 2008 From: kmedcalf at dessus.com (Keith Medcalf) Date: Wed, 03 Sep 2008 20:34:12 -0400 Subject: ingress SMTP Message-ID: > On Wed, Sep 03, 2008 at 12:58:53PM -0400, Nicholas Suan wrote: > > On Sep 3, 2008, at 12:49 PM, Jay R. Ashworth wrote: > > >You're forgetting that 587 *is authenticated, always*. > > I'm not sure how that makes much of a difference since the > > usual spam vector is malware that has (almost) complete > > control of the machine in the first place. > Well, that depends on MUA design, of course, but it's just > been pointed out to me that the RFC says MAY, not MUST. > Oops. > Does anyone bother to run an MSA on 587 and *not* require > authentication? Raises hand. Why would the requirements for authentication be different depending on the port used to connect to the MTA? No matter how a session comes into the MTA (port 25, 465, 587, anything else) and no matter whether it is encrypted or not, the requirement for authentication (which is always available and advertized), is based on a simple policy: - local delivery originating from a non-blacklisted or "internal/customer" address does not require authentication; - relay from "internal/customer" IP Addresses does not require authentication; - any connection from a blacklisted IP requires authentication or no mail will be accepted; - relay from "external/non-customer" IP Addresses requires authentication; Is there a valid reason why a different configuration is justified? As an aside, outbound port 25 traffic is also blocked except from the MTA. From jrhett at netconsonance.com Wed Sep 3 19:36:45 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Wed, 3 Sep 2008 17:36:45 -0700 Subject: Force10 Gear - Opinions In-Reply-To: <007401c90e25$6eaf2280$4c0d6780$@com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <00c401c9072b$f46a38c0$dd3eaa40$@com> <007401c90e25$6eaf2280$4c0d6780$@com> Message-ID: On Sep 3, 2008, at 5:30 PM, James Jun wrote: > uRPF was problematic back in PFC2 based platforms (i.e. SUP2) where > it is > further dependent upon unicast routes in FIB TCAM. uRPF was untenable on SUP2, not problematic. It wasn't possible above ... 3mb/sec? Guys, this isn't SOHO routing here. If you can't take a single gig interface at full burst with your feature, you don't have it. > uRPF currently works fine enough on PFC3 based sups, the only problem > however is currently only "one or the other" mode is supported for the > entire box, as opposed to per interface. For example, configuring > loose-mode uRPF in one interface, then configuring a strict-mode in > another > will result in entire box behaving as strict-mode interface for all > uRPF > enabled interfaces. Other than this caveat, I never had problems > with it. That's one hell of a caveot, given that you always want strict on your customers and loose on your transit links. > However, these uRPF issues are fully documented. Reading manuals and > documentation should help you avoid getting into operational > problems such > as "kept falling back and killing the units" scenario. This statement is patently false. The uRPF failures I dealt with were based entirely on the recommended settings, and were confirmed by Cisco. Last I heard (2 months ago) the problems remain. Cisco just isn't being honest with you about them. > Control plane policing via cp-policer works quite well on pfc3 based > 6500's. > This is ofcourse a very important feature (more important than uRPF in > today's internet IMO) that appears to be missing in f10 gear which > is what > Paul was saying earlier. Based on what? Other than some idea of "um, we can't meet BCP38 so lets call it unimportant?" -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From deleskie at gmail.com Wed Sep 3 19:38:42 2008 From: deleskie at gmail.com (jim deleskie) Date: Wed, 3 Sep 2008 21:38:42 -0300 Subject: Force10 Gear - Opinions In-Reply-To: References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <48B41978.9040201@sprunk.org> Message-ID: This is an awesome thread... in the 18mts I tested F10 vs Juniper vs Cisco I need see my Cisco sales rep push this hard :) On Wed, Sep 3, 2008 at 9:32 PM, Jo Rhett wrote: > On Aug 26, 2008, at 9:46 AM, Owen DeLong wrote: >> >> Bottom line, in a few years, everyone carrying full tables with F10 gear >> will probably need to >> upgrade all of their line cards to quad-cam. > > > Why is this statement being limited to F10? > > It appears to be true of every vendor. > > But why quad-cam? The dual-cam cards have indecent amounts of storage. > > -- > Jo Rhett > Net Consonance : consonant endings by net philanthropy, open source and > other randomness > > > > From aaron.glenn at gmail.com Wed Sep 3 20:56:34 2008 From: aaron.glenn at gmail.com (Aaron Glenn) Date: Wed, 3 Sep 2008 18:56:34 -0700 Subject: Force10 Gear - Opinions In-Reply-To: References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <48B41978.9040201@sprunk.org> Message-ID: <18f601940809031856m3866c7a4lccb44478667a7ab7@mail.gmail.com> On Wed, Sep 3, 2008 at 5:38 PM, jim deleskie wrote: > This is an awesome thread... in the 18mts I tested F10 vs Juniper vs > Cisco I need see my Cisco sales rep push this hard :) it's easy to push this hard when you have empirical evidence on your side but seriously, this is definitely a f10-nsp list thread and that place could use some love From blakjak at blakjak.net Wed Sep 3 21:01:48 2008 From: blakjak at blakjak.net (Mark Foster) Date: Thu, 4 Sep 2008 14:01:48 +1200 (NZST) Subject: ingress SMTP In-Reply-To: References: Message-ID: <60044.210.54.216.162.1220493708.squirrel@webmail.blakjak.net> > >> On Wed, Sep 03, 2008 at 12:58:53PM -0400, Nicholas Suan wrote: >> > On Sep 3, 2008, at 12:49 PM, Jay R. Ashworth wrote: > >> > >You're forgetting that 587 *is authenticated, always*. > >> > I'm not sure how that makes much of a difference since the >> > usual spam vector is malware that has (almost) complete >> > control of the machine in the first place. > >> Well, that depends on MUA design, of course, but it's just >> been pointed out to me that the RFC says MAY, not MUST. > >> Oops. > >> Does anyone bother to run an MSA on 587 and *not* require >> authentication? > > Raises hand. > > Why would the requirements for authentication be different depending on > the port used to connect to the MTA? > > No matter how a session comes into the MTA (port 25, 465, 587, anything > else) and no matter whether it is encrypted or not, the requirement for > authentication (which is always available and advertized), is based on a > simple policy: > > - local delivery originating from a non-blacklisted or > "internal/customer" address does not require authentication; > > - relay from "internal/customer" IP Addresses does not require > authentication; > > - any connection from a blacklisted IP requires authentication or no mail > will be accepted; > > - relay from "external/non-customer" IP Addresses requires > authentication; > > Is there a valid reason why a different configuration is justified? > > As an aside, outbound port 25 traffic is also blocked except from the MTA. > I'm glad someone finally posted the above. When I came 'up through the ranks' the policy could be explained simply, by separating POP3 and SMTP. The following is the users-perspective explanation I used to offer: - Mail from World to Client is checked via user/password check (POP3 in your mail client). Because its authenticated, it can be done from anywhere - subject to your ISPs policies on the subject. - Mail from Client to World is not authenticated (generally speaking) but what is checked is where you are. The rules: - Mail from ISP-IP to ISP-SMTP-SERVER is accepted regardless of destination. - Mail from anywhere else to ISP-SMTP-SERVER is accepted only if the destination is 'local' to the ISP. - There's no reason to do anything else as a general rule. Privately managed outbound mail solutions (such as a colo, or a corporate network, which subjects you to some other sort of validation before accepting your message) should be 'accountable' and in order to circumvent Port 25 blocking, should be found on other ports anyway. Port 25 traffic should be subject to the above. (I realise this doesnt account for SMTP-Auth. The reality today is that ISPs are blocking Port 25 to reduce spam from drones and that people should be prepared to work around this.) So in terms of the OP, I don't see why joe-user on a dynamic-IP home connection should need the ability to use port 25 to talk to anywhere but their local ISP SMTP server on a normal basis[1]. Theyre not doing MX lookups so theyre not going direct to remote MTAs[2]. Regardless of where they got the mail _from_, the outbound mail should be via SMTP to their local SMTP server.[3] If you separate inbound (pop3) and outbound (smtp) mail delivery in your thinking you can start to make sense of things (from a users perspective). This is always the tack i've taken when trying to educate users about why their email outbound doesn't work when theyre moving from ISP to ISP. (At which point you offer them your authenticated-another-way service, such as 587 with SMTP auth). [1] Customers with a specific need to do so should have the means to opt-out. I believe most of the ISPs in NZ who block 25-outbound from clients also offer this option. [2] Customers doing MX lookups are either drones or people with mail servers at home. The former are obviously the target of the block. The latter are likely going to be any one of: - Blocked by SORBS or similar as a dynamic IP - Running a mail server in breach of AUP - On a fixed IP and (theoretically) capable of securing their system and not being a drone or open mail relay (and being traceable via their ISP). [3] Note also [2]. Outbound mail is associated with your ISP and their SMTP service. Has nothing to do with inbound mail. Nothing. Nada. Zip. Or doesn't the rest of the world think like this? Mark. PS: It occurs to me that SPF has an influence here, if you're aggressively using it then you should also be offering alternatives to Port 25 SMTP. IMHO. From rubensk at gmail.com Wed Sep 3 21:06:22 2008 From: rubensk at gmail.com (Rubens Kuhl Jr.) Date: Wed, 3 Sep 2008 23:06:22 -0300 Subject: Force10 Gear - Opinions In-Reply-To: References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <00c401c9072b$f46a38c0$dd3eaa40$@com> <007401c90e25$6eaf2280$4c0d6780$@com> Message-ID: <6bb5f5b10809031906m67c18854nb4fe7260ad3e153@mail.gmail.com> > This statement is patently false. The uRPF failures I dealt with were based > entirely on the recommended settings, and were confirmed by Cisco. Last I > heard (2 months ago) the problems remain. Cisco just isn't being honest > with you about them. Would you mind telling us what is the scenario so we can avoid it ? Rubens From jra at baylink.com Wed Sep 3 21:27:00 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Wed, 3 Sep 2008 22:27:00 -0400 Subject: BCP blocking list for edge networks? (was: ingress SMTP) Message-ID: <20080904022700.GB27732@cgi.jachomes.com> Ok, mine is actualy even edgier than that; no transit at all, to paraphrase Steeley Dan. But does anyone have a pointer to a good set of ports to block in each direction through my Shorewall DNAT setup, preferably annotated? On reflection, that's actually only outbound; the necessity to set up inbound DNAT manually makes it a default-deny environment, which is one of the reasons that some people like NAT as a component of an edge firewall. 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 jscott at gravityfree.com Wed Sep 3 21:28:07 2008 From: jscott at gravityfree.com (Justin D. Scott) Date: Wed, 3 Sep 2008 22:28:07 -0400 Subject: ingress SMTP In-Reply-To: References: Message-ID: <86D9D642927746FFBA0F3BBC47A5F76C@lain> > iiNet a reasonably sized Aussie ISP has a web page > (specifially part of the 'My Account' page) where > you can, with a simple check box, choose to have > commonly abused ports blocked *for outgoing > connections* or not. That's great, and an excellent solution. Unfortunately many of the larger providers here in the United States are not as enlightened from my experience. Of course, YMMV. -Justin Scott From mailinglist at bangky.net Wed Sep 3 21:43:00 2008 From: mailinglist at bangky.net (Ang Kah Yik) Date: Thu, 4 Sep 2008 10:43:00 +0800 Subject: ingress SMTP Message-ID: Hmm.. if it helps - here's a link to an archived discussion on the same issue earlier this year. http://www.mail-archive.com/nanog at merit.edu/msg52598.html -- Ang Kah Yik (bangky) -- http://blog.bangky.net From ops.lists at gmail.com Wed Sep 3 21:51:42 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 4 Sep 2008 08:21:42 +0530 Subject: ingress SMTP In-Reply-To: References: Message-ID: you just found one? i think a few dozen over the last several years. surprised though, i thought this particular horse was finally dead after all the beatings it'd received. srs On Thu, Sep 4, 2008 at 8:13 AM, Ang Kah Yik wrote: > Hmm.. if it helps - here's a link to an archived discussion on the same > issue earlier this year. > > http://www.mail-archive.com/nanog at merit.edu/msg52598.html From ops.lists at gmail.com Wed Sep 3 22:08:58 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 4 Sep 2008 08:38:58 +0530 Subject: Why not go after bots? (was: ingress SMTP) In-Reply-To: <48BDCF78.8080009@mtcc.com> References: <20080903151617.A14277808@relayer.avian.org> <48BEFA6D.6070507@thewybles.com> <48BDCF78.8080009@mtcc.com> Message-ID: On Wed, Sep 3, 2008 at 5:12 AM, Michael Thomas wrote: > That seems to be the convention wisdom, but the science experiment > as it were in blocking port 25 doesn't seem to be correlated (must > less causated) with any drop in the spam rate. Because so far as I've > heard there isn't any such drop. Spammers and the rest are pretty > resourceful. Let's put it this way .. a lot of ISPs have already realized that which is why port 25 blocking or management is the basics. They do that and have done that for years (and various providers elsewhere still proudly claim "hey, we do outbound port 25 blocking, we're great!!!"). The real action is in walled gardens to automatically detect and isolate botted hosts till they're cleaned up Go talk to arbor, sandvine, perftech etc etc srs From bangky at gmail.com Wed Sep 3 22:23:49 2008 From: bangky at gmail.com (Ang Kah Yik) Date: Thu, 4 Sep 2008 11:23:49 +0800 Subject: ingress SMTP In-Reply-To: References: Message-ID: Nah. There have been plenty. This just happened to be one of the recent ones. But as you've rightly pointed out, the dead horse magically revives itself every once in a while ;) On Thu, Sep 4, 2008 at 10:51 AM, Suresh Ramasubramanian wrote: > you just found one? i think a few dozen over the last several years. > > surprised though, i thought this particular horse was finally dead > after all the beatings it'd received. > > srs > > On Thu, Sep 4, 2008 at 8:13 AM, Ang Kah Yik > wrote: > > Hmm.. if it helps - here's a link to an archived discussion on the same > > issue earlier this year. > > > > http://www.mail-archive.com/nanog at merit.edu/msg52598.html > -- Ang Kah Yik From frnkblk at iname.com Wed Sep 3 22:25:24 2008 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 3 Sep 2008 22:25:24 -0500 Subject: Why not go after bots? (was: ingress SMTP) In-Reply-To: References: <20080903151617.A14277808@relayer.avian.org> <48BEFA6D.6070507@thewybles.com> <48BDCF78.8080009@mtcc.com> Message-ID: If the service providers spent as much resources implementing systems that automatically erected a walled-garden for botted hosts as they have with bandwidth monitoring, our internet would look at lot cleaner. But apparently the money trail didn't lead them there. Frank -----Original Message----- From: Suresh Ramasubramanian [mailto:ops.lists at gmail.com] Sent: Wednesday, September 03, 2008 10:09 PM To: Michael Thomas Cc: nanog at nanog.org Subject: Re: Why not go after bots? (was: ingress SMTP) On Wed, Sep 3, 2008 at 5:12 AM, Michael Thomas wrote: > That seems to be the convention wisdom, but the science experiment > as it were in blocking port 25 doesn't seem to be correlated (must > less causated) with any drop in the spam rate. Because so far as I've > heard there isn't any such drop. Spammers and the rest are pretty > resourceful. Let's put it this way .. a lot of ISPs have already realized that which is why port 25 blocking or management is the basics. They do that and have done that for years (and various providers elsewhere still proudly claim "hey, we do outbound port 25 blocking, we're great!!!"). The real action is in walled gardens to automatically detect and isolate botted hosts till they're cleaned up Go talk to arbor, sandvine, perftech etc etc srs From frnkblk at iname.com Wed Sep 3 22:43:20 2008 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 3 Sep 2008 22:43:20 -0500 Subject: ingress SMTP In-Reply-To: References: Message-ID: If you leave port 587 un-authenticated then spammers just need to move their spambots to try port 587 *and* you're never sure who sent the message. If you're going to have the customer click a few extra buttons to get to port 587, might as well get them to authenticate. Authenticating port 587 is not the silver bullet, but it buys you a little bit. Frank -----Original Message----- From: Keith Medcalf [mailto:kmedcalf at dessus.com] Sent: Wednesday, September 03, 2008 7:34 PM To: nanog at nanog.org Subject: ingress SMTP > On Wed, Sep 03, 2008 at 12:58:53PM -0400, Nicholas Suan wrote: > > On Sep 3, 2008, at 12:49 PM, Jay R. Ashworth wrote: > > >You're forgetting that 587 *is authenticated, always*. > > I'm not sure how that makes much of a difference since the > > usual spam vector is malware that has (almost) complete > > control of the machine in the first place. > Well, that depends on MUA design, of course, but it's just > been pointed out to me that the RFC says MAY, not MUST. > Oops. > Does anyone bother to run an MSA on 587 and *not* require > authentication? Raises hand. Why would the requirements for authentication be different depending on the port used to connect to the MTA? No matter how a session comes into the MTA (port 25, 465, 587, anything else) and no matter whether it is encrypted or not, the requirement for authentication (which is always available and advertized), is based on a simple policy: - local delivery originating from a non-blacklisted or "internal/customer" address does not require authentication; - relay from "internal/customer" IP Addresses does not require authentication; - any connection from a blacklisted IP requires authentication or no mail will be accepted; - relay from "external/non-customer" IP Addresses requires authentication; Is there a valid reason why a different configuration is justified? As an aside, outbound port 25 traffic is also blocked except from the MTA. From pauldotwall at gmail.com Wed Sep 3 22:45:04 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Wed, 3 Sep 2008 23:45:04 -0400 Subject: Force10 Gear - Opinions In-Reply-To: <1AE55697-DD7B-4721-8FC1-610524A283B8@netconsonance.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808260026g1b1b7e97u64f7b3778e52ea4f@mail.gmail.com> <1AE55697-DD7B-4721-8FC1-610524A283B8@netconsonance.com> Message-ID: <620fd17c0809032045h3bf1f470mca541f8b8a26f3da@mail.gmail.com> On Wed, Sep 3, 2008 at 8:29 PM, Jo Rhett wrote: > On Aug 26, 2008, at 12:26 AM, Paul Wall wrote: >> >> Routing n*GE at line rate isn't difficult these days, even with all >> 64-byte packets and other "DoS" conditions. >> >> Linksys, D-Link, SMC, etc are able to pull it off on the layer 3 >> switches sold at Fry's for a couple benjamins a pop. :) > > Sorry, I thought you were serious. I am. All of these boxes can forward packets at line rate, and list for a fraction of the price of the Force 10 S-Series. I'll be correcting your other posts shortly! Drive Slow, Paul Wall From bfeeny at mac.com Wed Sep 3 22:54:43 2008 From: bfeeny at mac.com (Brian Feeny) Date: Wed, 03 Sep 2008 23:54:43 -0400 Subject: Force10 Gear - Opinions In-Reply-To: References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <00c401c9072b$f46a38c0$dd3eaa40$@com> <007401c90e25$6eaf2280$4c0d6780$@com> Message-ID: <088C98AB-B1A6-46F5-AB2B-78D3C137A899@mac.com> On Sep 3, 2008, at 8:36 PM, Jo Rhett wrote: >> > > That's one hell of a caveot, given that you always want strict on > your customers and loose on your transit links. > Personally I have always avoided combining customers and transit providers on the same routers in ISP environments. Brian From joelja at bogus.com Thu Sep 4 01:36:39 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 03 Sep 2008 23:36:39 -0700 Subject: Force10 Gear - Opinions In-Reply-To: <620fd17c0809032045h3bf1f470mca541f8b8a26f3da@mail.gmail.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808260026g1b1b7e97u64f7b3778e52ea4f@mail.gmail.com> <1AE55697-DD7B-4721-8FC1-610524A283B8@netconsonance.com> <620fd17c0809032045h3bf1f470mca541f8b8a26f3da@mail.gmail.com> Message-ID: <48BF81F7.6080202@bogus.com> Paul Wall wrote: > On Wed, Sep 3, 2008 at 8:29 PM, Jo Rhett wrote: >> On Aug 26, 2008, at 12:26 AM, Paul Wall wrote: >>> Routing n*GE at line rate isn't difficult these days, even with all >>> 64-byte packets and other "DoS" conditions. >>> >>> Linksys, D-Link, SMC, etc are able to pull it off on the layer 3 >>> switches sold at Fry's for a couple benjamins a pop. :) >> Sorry, I thought you were serious. > > I am. All of these boxes can forward packets at line rate, and list > for a fraction of the price of the Force 10 S-Series. a dlink dsg-3627g is a quite a few benjamins... but given that switch asics for said class of products are widely available and cheap, the difference between vender a and vendor b in that class of switch is futher up in the software stack. > I'll be correcting your other posts shortly! > > Drive Slow, > Paul Wall > From pauldotwall at gmail.com Thu Sep 4 02:47:01 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Thu, 4 Sep 2008 03:47:01 -0400 Subject: Force10 Gear - Opinions In-Reply-To: <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> Message-ID: <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> On Wed, Sep 3, 2008 at 8:28 PM, Jo Rhett wrote: > For equivalent redundancy and ports, the Force10 is always cheaper - even > just in list price. (on the E-series -- Cisco has some cheaper options than > the S-series so I've heard - don't care) Some food for thought, comparing apples to apples... FORCE 10 ********************* CH-E300-BNA8-L $35,000.00 E300 110V AC Terascale Chassis Bundle: 6-slot E300 chassis with 400 Gb backplane, fan subsystem, 3 AC Power Supplies (CC-E300-1200W-AC) 1 Route Processor Module (EF3), 2 Switch Fabric Modules LC-EF3-1GE-24P $30,000.00 E300 Terascale 24-port Gigabit Ethernet line card - SFP optics required (series EF3) CC-E300-1200W-AC $4,000.00 E300 1200W/800W AC Power Supply CC-E-SFM3 $12,500.00 E-Series Switch Fabric Module LC-EF3-RPM $30,000.00E300 Terascale Route processor module (series EF3) ** BASIC CONFIG WITH 24 GIG-E (SFP PORTS): $65000.00 (USD) ** CISCO **************** WS-C6503-E Catalyst 6500 Enhanced 3-slot chassis,4RU,no PS,no Fan Tray 2500 WS-SUP720-3BXL= Catalyst 6500/Cisco 7600 Supervisor 720 Fabric MSFC3 PFC3BXL 40000 WS-X6724-SFP= Catalyst 6500 24-port GigE Mod: fabric-enabled (Req. SFPs) 15000 WS-CAC-3000W= Catalyst 6500 3000W AC power supply (spare) 3000 PWR-950-DC= Spare 950W DC P/S for CISCO7603/Cat 6503 1245 WS-C6503-E-FAN= Catalyst 6503-E Chassis Fan Tray 495 ** BASIC CONFIG WITH 24 GIG-E (SFP PORTS) (not counting two bonus ports on Sup :) 62240.00 (USD) ** Please realize that the above is list vs. list. Cisco 6500 series hardware is extremely popular in the secondary market, with discounts of 80% or greater on linecards, etc common, furthering the argument that Cisco is the cheaper of the two solutions. >>>> As a box designed with the enterprise datacenter in mind, the E-series >>>> looks to be missing several key service provider features, including >>>> MPLS and advanced control plane filtering/policing. >>> >>> Ah, because Cisco does either of these in hardware? >> >> Yes, they do, on the s720-3B and better. > > No, they don't. There are *no* *zero* providers doing line-speed uRPF on > Cisco for a reason. Stop reading, start testing. Cisco absolutely does MPLS and control-plane policing in hardware on the SUP720 (3B and higher), ditto uRPF. Force 10 doesn't even support the first two last I checked! On the subject of uRPF, it's true, Cisco's implementation is less than ideal, and is not without caveats. Nobody seems to get this right, though Juniper tries the hardest. Practically speaking, it can be made to work just fine. Possible solutions commonplace among larger tier 1/2 providers include having your OSS auto-generate an inbound access-list against a list of networks routed to the customer, or just applying a boilerplate "don't allow bad stuff" filter on the ingress. uRPF strict as a configuration default, on customers without possible asymmetry (multihoming, one-way tunneling, etc) is not a bad default. But when the customers increase in complexity, the time might come to relax things some. It's certainly not a be-all-end-all. And it's been demonstrated time after time here that anti-spoof/bogon filtering isn't even a factor in most large-scale attacks on the public Internet these days. Think massively sized, well connected, botnets. See also CP attacks (which, again, the F10 can't even help you with). Drive Slow, Paul Wall From mtinka at globaltransit.net Thu Sep 4 03:34:37 2008 From: mtinka at globaltransit.net (Mark Tinka) Date: Thu, 4 Sep 2008 16:34:37 +0800 Subject: Force10 Gear - Opinions In-Reply-To: <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> Message-ID: <200809041634.38615.mtinka@globaltransit.net> On Thursday 04 September 2008 15:47:01 Paul Wall wrote: > uRPF strict as a configuration default, on customers > without possible asymmetry (multihoming, one-way > tunneling, etc) is not a bad default. But when the > customers increase in complexity, the time might come to > relax things some. It's certainly not a be-all-end-all. Our experience with uRPF has been some unpleasant badness when dealing with a few private peers. Our private peering routers don't hold full routes (naturally), so we had to relax (even) the loose-mode uRPF scheme we had for this because some of our peers were leaking our routes to the Internet. Customer-facing, strict-mode uRPF is standard practice across the board for all customers single-homed to us. Customers for whom we know have multiple connections get loose-mode uRPF. For good measure, each edge router has outbound ACL's on the core-facing interfaces catching RFC 1918 and RFC 3330 junk. On border (transit) routers, we employ loose-mode uRPF with no issues, since these carry a full table. In addition, we catch inbound RFC 1918 and RFC 3330 with ACL's; and just to see how crazy things get, we stick our own prefixes in there since we really shouldn't be seeing them as sources from the wild. It's quite interesting how many matches we log, particularly for own addresses, on transit and peering links. Of course, the RFC 1918 and RFC 3330 are not without increment as well. No filtering in the core. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: From mtinka at globaltransit.net Thu Sep 4 03:34:37 2008 From: mtinka at globaltransit.net (Mark Tinka) Date: Thu, 4 Sep 2008 16:34:37 +0800 Subject: Force10 Gear - Opinions In-Reply-To: <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> Message-ID: <200809041634.38615.mtinka@globaltransit.net> On Thursday 04 September 2008 15:47:01 Paul Wall wrote: > uRPF strict as a configuration default, on customers > without possible asymmetry (multihoming, one-way > tunneling, etc) is not a bad default. But when the > customers increase in complexity, the time might come to > relax things some. It's certainly not a be-all-end-all. Our experience with uRPF has been some unpleasant badness when dealing with a few private peers. Our private peering routers don't hold full routes (naturally), so we had to relax (even) the loose-mode uRPF scheme we had for this because some of our peers were leaking our routes to the Internet. Customer-facing, strict-mode uRPF is standard practice across the board for all customers single-homed to us. Customers for whom we know have multiple connections get loose-mode uRPF. For good measure, each edge router has outbound ACL's on the core-facing interfaces catching RFC 1918 and RFC 3330 junk. On border (transit) routers, we employ loose-mode uRPF with no issues, since these carry a full table. In addition, we catch inbound RFC 1918 and RFC 3330 with ACL's; and just to see how crazy things get, we stick our own prefixes in there since we really shouldn't be seeing them as sources from the wild. It's quite interesting how many matches we log, particularly for own addresses, on transit and peering links. Of course, the RFC 1918 and RFC 3330 are not without increment as well. No filtering in the core. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: From jfmezei at vaxination.ca Thu Sep 4 06:05:52 2008 From: jfmezei at vaxination.ca (=?ISO-8859-1?Q?Jean-Fran=E7ois_Mezei?=) Date: Thu, 04 Sep 2008 07:05:52 -0400 Subject: ingress SMTP In-Reply-To: References: Message-ID: <48BFC110.3070101@vaxination.ca> re: intercepting port 25 calls and routing them to the ISP's own SMTP server. Consider an employee of chocolate.com working from home. he connects to Chocolate.com's SMTP server to send mail, but his ISP intercepts the connection and routes the email via its own. The email will then be sent by the ISP's SMTP server. In a context where SPF has been implemented, it means that the email will have been sent by an SMTP server that has not been authorized to send emails from "chocolate.com" and thus rejected by the recipient, and it is not clear how the rejection message would be handled. Also, the ISP might not only intercept the call, but then reject the email because it doesn't have a "from" from the ISP's domain. Secondly, and more importantly. If you are dealing with mass market ISPs who have clear "no servers" policies, then no customer would have legitimate need to run an SMTP server from home. However, there are smaller ISPs who do cater to SOHO /small businesses and those would have legitimate needs to run their own SMTP servers, and if the small ISP ends up using "last mile" from a large ISP, that large ISP would be negatively impacting the smaller ISP's customers. One option is to block port 25, but allow unblocking on an individual basis to those who have fixed IPs or make a good justification to their ISP that they need the port unblocked. In terms of mass-market people using email services from the outside of their ISP (hotmail, yahoo, gmail), then I guess port 587 would be the required way to get it done). From davei at otd.com Thu Sep 4 06:54:11 2008 From: davei at otd.com (Dave Israel) Date: Thu, 04 Sep 2008 07:54:11 -0400 Subject: Force10 Gear - Opinions In-Reply-To: <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> Message-ID: <48BFCC63.1030006@otd.com> Paul Wall wrote: > > Please realize that the above is list vs. list. Cisco 6500 series > hardware is extremely popular in the secondary market, with discounts > of 80% or greater on linecards, etc common, furthering the argument > that Cisco is the cheaper of the two solutions. > Secondary market prices aren't a fair measure, unless you include the corresponding cost for software and support. And the fact is, when we put this out for an RFP, we ended up with Force10 having the lowest price by a fair margin; the closest competitor in price was Foundry, with Cisco a distant third. List prices aren't a good measure o actual price; they're a number for salesmen to compare their discount to to make people feel special. In short: You can get the Force10 cheap. From dot at dotat.at Thu Sep 4 07:51:18 2008 From: dot at dotat.at (Tony Finch) Date: Thu, 4 Sep 2008 13:51:18 +0100 Subject: ingress SMTP In-Reply-To: <20080903190015.GS8979@cgi.jachomes.com> References: <20080903151617.A14277808@relayer.avian.org> <48BEB3C3.1070600@gravityfree.com> <20080903161400.GI8979@cgi.jachomes.com> <48BEBDF4.9040109@mtcc.com> <20080903164941.GL8979@cgi.jachomes.com> <20080903190015.GS8979@cgi.jachomes.com> Message-ID: On Wed, 3 Sep 2008, Jay R. Ashworth wrote: > > Well, that depends on MUA design, of course, but it's just been pointed > out to me that the RFC says MAY, not MUST. Note that there are TWO relevant RFCs: RFC 4409 and RFC 5068. The latter says: 3.1. Best Practices for Submission Operation Submission Authentication: MSAs MUST perform authentication on the identity asserted during all mail transactions on the SUBMISSION port, even for a message having a RCPT TO address that would not cause the message to be relayed outside of the local administrative domain. Tony. -- f.anthony.n.finch http://dotat.at/ FISHER GERMAN BIGHT: SOUTHWESTERLY 5 TO 7, OCCASIONALLY GALE 8 IN GERMAN BIGHT, DECREASING 4 AT TIMES. ROUGH OR VERY ROUGH, BECOMING MODERATE LATER. SQUALLY SHOWERS. MODERATE OR GOOD. From dot at dotat.at Thu Sep 4 07:54:13 2008 From: dot at dotat.at (Tony Finch) Date: Thu, 4 Sep 2008 13:54:13 +0100 Subject: ingress SMTP In-Reply-To: <48BFC110.3070101@vaxination.ca> References: <48BFC110.3070101@vaxination.ca> Message-ID: On Thu, 4 Sep 2008, Jean-Fran?ois Mezei wrote: > > Consider an employee of chocolate.com working from home. he connects to > Chocolate.com's SMTP server to send mail, but his ISP intercepts the > connection and routes the email via its own. The email will then be sent > by the ISP's SMTP server. A user that has this problem has failed to choose the right port number and set up SMTP authentication and TLS properly. Tony. -- f.anthony.n.finch http://dotat.at/ ROCKALL MALIN: MAINLY NORTHERLY 4 OR 5 INCREASING 5 TO 7, PERHAPS GALE 8 LATER IN ROCKALL. MODERATE OR ROUGH. SHOWERS. GOOD. From dot at dotat.at Thu Sep 4 08:27:56 2008 From: dot at dotat.at (Tony Finch) Date: Thu, 4 Sep 2008 14:27:56 +0100 Subject: ingress SMTP In-Reply-To: References: Message-ID: On Wed, 3 Sep 2008, Keith Medcalf wrote: > > Why would the requirements for authentication be different depending on > the port used to connect to the MTA? It's easier to configure the MTA if you make a distinction between server-to-server traffic and client-to-server traffic. In fact my systems distinguish three classes of traffic: MX, message submission, and smarthost. The MX service has lots of anti-spam features. You want to separate it from the others so that techniques like teergrubing don't make message submission painfully slow. You can also avoid interoperability problems with server-to-server TLS. You can limit the number of connections used by the MX service to that when it is being hammered by spammers, you can reserve some capacity so that message submission and outgoing relay still work. Having a message submission service that always requires TLS and authentication makes it easier for users to check their configuration. A mistake such as not turning on AUTH can be hidden when they test on their home network, only to be discovered later when they are roaming far from tech support. Separating your smarthost (outgoing relay service) from your MX can avoid some strange problems. Back in the dim and distant past before remote AUTHed message submission and before separate MX and smarthost, our roaming users who failed to change their smarthost setting would have working email when contacting colleagues but not anyone else, with a mysterious "relaying is not permitted" error instead of something clear and helpful. There's also some advantage to making it harder for spammers to work out the name of your smarthost: we once (years ago) had a problem with an open web proxy that spammers used as the first half of a two-stage open relay, the second half of which was the MX of the proxy's parent domain. We separate these functions by having separate names and IP addresses for each one. They are all just facets of the same MTA, so we don't have to maintainn lots of different configurations. Tony. -- f.anthony.n.finch http://dotat.at/ LUNDY FASTNET IRISH SEA: WESTERLY OR SOUTHWESTERLY 4 OR 5, BECOMING CYCLONIC OR NORTHEASTERLY 5 TO 7, PERHAPS GALE 8 LATER. ROUGH OR VERY ROUGH. RAIN OR SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. From alec.berry at restontech.com Thu Sep 4 08:43:59 2008 From: alec.berry at restontech.com (Alec Berry) Date: Thu, 04 Sep 2008 09:43:59 -0400 Subject: ingress SMTP In-Reply-To: <200809032141.m83LfIf4009727@mail.r-bonomi.com> References: <200809032141.m83LfIf4009727@mail.r-bonomi.com> Message-ID: <48BFE61F.8040509@restontech.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert Bonomi wrote: > One small data-point -- on a personal vanity domain, approximately 2/3 of > all the spam (circa 15k junk emails/month) was 'direct to inbound MX' > transmissions. The vast majority of this is coming from end-user machines > outside of North America. This confirms the limited data I have. I configure my edge firewall (pf) to drop anything to/from the Spamhaus DROP list, as well as sendmail to use their XBL. The DROP list seems like it blocks mostly MX lookups (nice to see the blocking of mail start so early in the process!), so it is hard to say how many SMTP connections never happen (remote server/bot does not know where to connect). The XBL list, which is mostly residential IPs around the world, seems to be the single most effective technique in blocking incoming traffic-- on port 25. Obviously, these connections are coming from ISPs that do *not* block egress TCP 25. Slightly off topic-- I found it quite easy to configure the DROP list to work with pf (or is that the other way around?). I would be happy to share the small Perl script that updates the pf table. When I configured the DROP list on a free public wireless system I maintain, I was amazed at how much egress traffic it blocked-- obviously rogue/bad/evil webservers, IRC hosts, etc. I wonder if anyone else is using it that way? ... alec - -- `____________ / Alec Berry \______________________________ | Senior Partner and Director of Technology \ | PGP/GPG key 0xE8E9030F | | http://alec.restontech.com/#PGP | |-------------------------------------------| | RestonTech, Ltd. | | http://www.restontech.com/ | | Phone: (703) 234-2914 | \___________________________________________/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIv+YdREO1P+jpAw8RAnWzAKDxOmneR6j6DBVyo5/CO1wRYngorQCgo9SJ sArBQqQStX7zIuYK3qo1El0= =C2FM -----END PGP SIGNATURE----- From james at towardex.com Thu Sep 4 09:24:53 2008 From: james at towardex.com (James Jun) Date: Thu, 4 Sep 2008 10:24:53 -0400 Subject: Force10 Gear - Opinions In-Reply-To: <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> Message-ID: <00d501c90e99$ffb4e480$ff1ead80$@com> > uRPF strict as a configuration default, on customers without possible > asymmetry (multihoming, one-way tunneling, etc) is not a bad default. > But when the customers increase in complexity, the time might come to > relax things some. It's certainly not a be-all-end-all. And it's > been demonstrated time after time here that anti-spoof/bogon filtering > isn't even a factor in most large-scale attacks on the public Internet > these days. Think massively sized, well connected, botnets. See also > CP attacks (which, again, the F10 can't even help you with). Indeed... In today's internet, protecting your own box (cp-policer/control plane filtering) is far more important IMO than implementing BCP38 when much of attack traffic comes from legitimate IP sources anyway (see botnets). james From marka at isc.org Thu Sep 4 09:28:40 2008 From: marka at isc.org (Mark Andrews) Date: Fri, 5 Sep 2008 00:28:40 +1000 (EST) Subject: ingress SMTP In-Reply-To: <48BFE61F.8040509@restontech.com> References: <200809032141.m83LfIf4009727@mail.r-bonomi.com> Message-ID: <200809041428.m84ESehc088883@drugs.dv.isc.org> In article <48BFE61F.8040509 at restontech.com> you write: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Robert Bonomi wrote: > >> One small data-point -- on a personal vanity domain, approximately 2/3 of >> all the spam (circa 15k junk emails/month) was 'direct to inbound MX' >> transmissions. The vast majority of this is coming from end-user machines >> outside of North America. > >This confirms the limited data I have. I configure my edge firewall (pf) >to drop anything to/from the Spamhaus DROP list, as well as sendmail to >use their XBL. The DROP list seems like it blocks mostly MX lookups >(nice to see the blocking of mail start so early in the process!), so it >is hard to say how many SMTP connections never happen (remote server/bot >does not know where to connect). The XBL list, which is mostly >residential IPs around the world, seems to be the single most effective >technique in blocking incoming traffic-- on port 25. Obviously, these >connections are coming from ISPs that do *not* block egress TCP 25. You do realise that there a mail clients that check MX records *before* submitting email (or before on sending the email) so that typos get detected in the client before any email is sent from the client. But you would never see those false positives. I know they exist because I've experienced them because I work from home and even though I tunnel email out via the office servers I prefer the typos to be caught locally. I doubt this will change your mind but it might stop someone else from making a bad decision to do what you are doing. Mark >Slightly off topic-- I found it quite easy to configure the DROP list to >work with pf (or is that the other way around?). I would be happy to >share the small Perl script that updates the pf table. When I configured >the DROP list on a free public wireless system I maintain, I was amazed >at how much egress traffic it blocked-- obviously rogue/bad/evil >webservers, IRC hosts, etc. > >I wonder if anyone else is using it that way? > >... >alec > >- -- >`____________ >/ Alec Berry \______________________________ >| Senior Partner and Director of Technology \ >| PGP/GPG key 0xE8E9030F | >| http://alec.restontech.com/#PGP | >|-------------------------------------------| >| RestonTech, Ltd. | >| http://www.restontech.com/ | >| Phone: (703) 234-2914 | >\___________________________________________/ >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.2 (MingW32) >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > >iD8DBQFIv+YdREO1P+jpAw8RAnWzAKDxOmneR6j6DBVyo5/CO1wRYngorQCgo9SJ >sArBQqQStX7zIuYK3qo1El0= >=C2FM >-----END PGP SIGNATURE----- > From dgc at uchicago.edu Thu Sep 4 09:31:11 2008 From: dgc at uchicago.edu (David Champion) Date: Thu, 4 Sep 2008 09:31:11 -0500 Subject: ingress SMTP In-Reply-To: References: <20080903151617.A14277808@relayer.avian.org> <48BEB3C3.1070600@gravityfree.com> <20080903161400.GI8979@cgi.jachomes.com> <48BEBDF4.9040109@mtcc.com> <20080903164941.GL8979@cgi.jachomes.com> <20080903190015.GS8979@cgi.jachomes.com> Message-ID: <20080904143111.GN16311@monkey.uchicago.edu> > > Well, that depends on MUA design, of course, but it's just been pointed > > out to me that the RFC says MAY, not MUST. (That was me.) > Note that there are TWO relevant RFCs: RFC 4409 and RFC 5068. The latter > says: > > 3.1. Best Practices for Submission Operation Thanks, Tony. I hadn't taken account of superceding RFCs, and quoted 2476 to Jay. 2476 permits authN without encouraging or requiring it, but 4409 both obsoletes 2476 and makes authN mandatory, so it's more even than a best practice. It's the law, to the extent that two sites involved in a dispute may or may not consider RFC to be law. But as I noted privately, sendmail for one enables MSP out of the box without authentication -- or did the last few times I set it up -- so there's certainly a significant base of systems that at least are running MSP on 587 without requiring authentication. In such cases, blocking ports is just whacking moles, whether you ticket and fine the moles for violating RFC or not. -- -D. dgc at uchicago.edu NSIT University of Chicago From alec.berry at restontech.com Thu Sep 4 09:57:24 2008 From: alec.berry at restontech.com (Alec Berry) Date: Thu, 04 Sep 2008 10:57:24 -0400 Subject: ingress SMTP In-Reply-To: <200809041428.m84ESehc088883@drugs.dv.isc.org> References: <200809032141.m83LfIf4009727@mail.r-bonomi.com> <200809041428.m84ESehc088883@drugs.dv.isc.org> Message-ID: <48BFF754.5040702@restontech.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark Andrews wrote: >> You do realise that there a mail clients that check MX >> records *before* submitting email (or before on sending the >> email) so that typos get detected in the client before any >> email is sent from the client. I think you are not familiar with the difference between the DROP list and the XBL. The DROP list is *not* an RBL! I do not allow any traffic at all to or from the DROP list-- including MX lookups. I can't think of any good reasons why I would. The XBL is used only to block mail transport-- it is configured in sendmail, not at the firewall. The scenario you lay out will still work: - - end user on a dial up that happens to be on the XBL (common) - - end user queries MX records, either directly or via their name server - - end user submits mail to their SMTP server (not on the XBL) - - SMTP server transports mail to my system Unless one of those systems mentioned above is a hijacked name server in Kyiv (and thus on the DROP list), everything will work. ... alec - -- `____________ / Alec Berry \______________________________ | Senior Partner and Director of Technology \ | PGP/GPG key 0xE8E9030F | | http://alec.restontech.com/#PGP | |-------------------------------------------| | RestonTech, Ltd. | | http://www.restontech.com/ | | Phone: (703) 234-2914 | \___________________________________________/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIv/dTREO1P+jpAw8RAqiyAKDJt7FbFvplXB1JTe+dKDOOSXUijQCdH/cZ 4m4o9vE5FS96huARs2Rq5yU= =Paen -----END PGP SIGNATURE----- From jra at baylink.com Thu Sep 4 10:19:32 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Thu, 4 Sep 2008 11:19:32 -0400 Subject: GLBX De-Peers Intercage [Was: RE: Washington Post: Atrivo/Intercag e, w hy are we peering with the American RBN?] In-Reply-To: <17826.1220281700@turing-police.cc.vt.edu> References: <20080901.014812.9559.0@webmail03.vgs.untd.com> <7679.1220261807@turing-police.cc.vt.edu> <48BBFA64.8020100@cox.net> <17826.1220281700@turing-police.cc.vt.edu> Message-ID: <20080904151932.GH32409@cgi.jachomes.com> On Mon, Sep 01, 2008 at 11:08:20AM -0400, Valdis.Kletnieks at vt.edu wrote: > > What is your price for cocaine? > > No, seriously.. If, as some estimates have it, 80% of the traffic is P2P, and > as other estimates have it, 90% of that is copyright-infringing, then if that > traffic disappears, anybody who was selling transit for that traffic is > going to take a *big* revenue hit. Not for long. The *problem* is edge customers having to continually increase the size of their pipes to make room for the good stuff amongst the crap. If the crap goes away, there will then be room for the chicken and egg problem with the steady march of IPTV etc to finally take off for real, I should think... > I think it's very disingenuous to pretend that there have been *no* providers > that haven't said to themselves "We're selling to scum, but it pays the bills, > and we'd be in bankruptcy court otherwise..." Sure. And those are the people we don't *care* if they take it in the wallet, no? 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 jrhett at netconsonance.com Thu Sep 4 11:35:34 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 4 Sep 2008 09:35:34 -0700 Subject: Cisco uRPF failures In-Reply-To: <6bb5f5b10809031906m67c18854nb4fe7260ad3e153@mail.gmail.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <00c401c9072b$f46a38c0$dd3eaa40$@com> <007401c90e25$6eaf2280$4c0d6780$@com> <6bb5f5b10809031906m67c18854nb4fe7260ad3e153@mail.gmail.com> Message-ID: <5188BB8F-8EFC-4FCA-BA9F-E36E6C3CEB81@netconsonance.com> (changing subject line) On Sep 3, 2008, at 7:06 PM, Rubens Kuhl Jr. wrote: >> This statement is patently false. The uRPF failures I dealt with >> were based >> entirely on the recommended settings, and were confirmed by Cisco. >> Last I >> heard (2 months ago) the problems remain. Cisco just isn't being >> honest >> with you about them. > > Would you mind telling us what is the scenario so we can avoid it ? That's the surprising thing -- no scenario. Very basic configuration. Enabling uRPF and then hitting it with a few gig of non-routable packets consistently caused the sup module to stop talking on the console, and various other problems to persist throughout the unit, ie no arp response. We were able to simulate this with two 2 pc's direction connected to a 6500 in a lab. If I remember right, we had to enable CEF to see the problem, but since CEF is a kitchen sink that dozens of other features require you simply couldn't disable it. We also discovered problems related to uRPF and load balanced links, but those were difficult to reproduce in the lab and we couldn't affect their peering, so we had to disable uRPF and ignore so I don't have much details. I kept thinking that this was a serious problem that Cisco would address quickly, but that turns out not to be the case. To this day I've never found a network operator using uRPF on Cisco gear. (note: network operator. it's probably fine for several-hundred-meg enterprise sites) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Thu Sep 4 11:36:39 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 4 Sep 2008 09:36:39 -0700 Subject: Force10 Gear - Opinions In-Reply-To: <620fd17c0809032045h3bf1f470mca541f8b8a26f3da@mail.gmail.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808260026g1b1b7e97u64f7b3778e52ea4f@mail.gmail.com> <1AE55697-DD7B-4721-8FC1-610524A283B8@netconsonance.com> <620fd17c0809032045h3bf1f470mca541f8b8a26f3da@mail.gmail.com> Message-ID: On Sep 3, 2008, at 8:45 PM, Paul Wall wrote: >>> Linksys, D-Link, SMC, etc are able to pull it off on the layer 3 >>> switches sold at Fry's for a couple benjamins a pop. :) >> > I am. All of these boxes can forward packets at line rate, and list > for a fraction of the price of the Force 10 S-Series. You and I (and any real network operator) must have different definitions of "forward at line rate". -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Thu Sep 4 11:40:35 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 4 Sep 2008 09:40:35 -0700 Subject: Force10 Gear - Opinions In-Reply-To: <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> Message-ID: <932F4ABF-B1B4-46FF-8155-E799044E3697@netconsonance.com> On Sep 4, 2008, at 12:47 AM, Paul Wall wrote: > Some food for thought, comparing apples to apples... > > FORCE 10 > ********************* > CH-E300-BNA8-L $35,000.00 > E300 110V AC Terascale Chassis Bundle: 6-slot E300 chassis > with 400 Gb backplane, fan subsystem, 3 AC Power Supplies > (CC-E300-1200W-AC) 1 Route Processor Module (EF3), 2 > Switch Fabric Modules > LC-EF3-1GE-24P $30,000.00 > E300 Terascale 24-port Gigabit Ethernet line card - SFP optics > required (series EF3) > CC-E300-1200W-AC $4,000.00 E300 1200W/800W AC Power Supply > CC-E-SFM3 $12,500.00 E-Series Switch Fabric Module > LC-EF3-RPM $30,000.00E300 Terascale Route processor module (series > EF3) > ** BASIC CONFIG WITH 24 GIG-E (SFP PORTS): $65000.00 (USD) ** You added a third SFM3 which has no place to go in this chassis. So $52,500 versus $62,240 for the Cisco. > Please realize that the above is list vs. list. Cisco 6500 series > hardware is extremely popular in the secondary market, with discounts > of 80% or greater on linecards, etc common, furthering the argument > that Cisco is the cheaper of the two solutions. Then you need to add recertify cost, which isn't cheap. And given that you can purchase Force10 stuff *NEW* at 60% discount, you're pitting new against used for similar prices. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Thu Sep 4 11:42:12 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 4 Sep 2008 09:42:12 -0700 Subject: uRPF In-Reply-To: <200809041634.38615.mtinka@globaltransit.net> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <200809041634.38615.mtinka@globaltransit.net> Message-ID: On Sep 4, 2008, at 1:34 AM, Mark Tinka wrote: > catch inbound RFC 1918 and RFC 3330 with ACL's; and just to > see how crazy things get, we stick our own prefixes in > there since we really shouldn't be seeing them as sources > from the wild. So you are talking single site, or single peering location? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Thu Sep 4 11:45:15 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 4 Sep 2008 09:45:15 -0700 Subject: BCP38 dismissal In-Reply-To: <00d501c90e99$ffb4e480$ff1ead80$@com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> Message-ID: <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> On Sep 4, 2008, at 7:24 AM, James Jun wrote: > Indeed... In today's internet, protecting your own box (cp-policer/ > control > plane filtering) is far more important IMO than implementing BCP38 > when much > of attack traffic comes from legitimate IP sources anyway (see > botnets). I'm sorry, but nonsense statements such as these burn the blood. Sure, yes, protecting yourself is so much more important than protecting anyone else. Anyone else want to stand up and join the "I am an asshole" club? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From bambenek at gmail.com Thu Sep 4 11:50:13 2008 From: bambenek at gmail.com (John C. A. Bambenek) Date: Thu, 4 Sep 2008 11:50:13 -0500 Subject: BCP38 dismissal In-Reply-To: <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> Message-ID: Count me in. There is no reason to limit our defenses to the one thing that we think is important at one instance in time... attackers change and adapt and multimodal defense is simply good policy. On Thu, Sep 4, 2008 at 11:45 AM, Jo Rhett wrote: > On Sep 4, 2008, at 7:24 AM, James Jun wrote: >> >> Indeed... In today's internet, protecting your own box (cp-policer/control >> plane filtering) is far more important IMO than implementing BCP38 when >> much >> of attack traffic comes from legitimate IP sources anyway (see botnets). > > > I'm sorry, but nonsense statements such as these burn the blood. Sure, yes, > protecting yourself is so much more important than protecting anyone else. > > Anyone else want to stand up and join the "I am an asshole" club? > > -- > Jo Rhett > Net Consonance : consonant endings by net philanthropy, open source and > other randomness > > > > From james at towardex.com Thu Sep 4 11:51:21 2008 From: james at towardex.com (James Jun) Date: Thu, 4 Sep 2008 12:51:21 -0400 Subject: BCP38 dismissal In-Reply-To: <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> Message-ID: <010d01c90eae$75ddac50$619904f0$@com> > > I'm sorry, but nonsense statements such as these burn the blood. > Sure, yes, protecting yourself is so much more important than > protecting anyone else. Indeed it is important. And we were discussing about the fact that Force10 does not even offer this critical feature. > > Anyone else want to stand up and join the "I am an asshole" club? You are falsely claiming that somehow we're "dismissing" BCP38 or otherwise writing it off as some kind of non-important hassle. You are confused and misinformed as to the concurrent nature of the ongoing discussion and your assumptions are far from what I personally think about BCP38. It appears you are the first member of "I am an asshole" club by the strict title definition. james From jrhett at netconsonance.com Thu Sep 4 11:52:22 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 4 Sep 2008 09:52:22 -0700 Subject: BCP38 dismissal In-Reply-To: References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> Message-ID: <2EB68782-AF2E-4E5E-8194-43A4C355E302@netconsonance.com> Count you which way? You seem to agree with me. Everyone should be doing both, not discounting BCP38 because they aren't seeing an attack right now. On Sep 4, 2008, at 9:50 AM, John C. A. Bambenek wrote: > Count me in. > > There is no reason to limit our defenses to the one thing that we > think is important at one instance in time... attackers change and > adapt and multimodal defense is simply good policy. > > On Thu, Sep 4, 2008 at 11:45 AM, Jo Rhett > wrote: >> On Sep 4, 2008, at 7:24 AM, James Jun wrote: >>> >>> Indeed... In today's internet, protecting your own box (cp-policer/ >>> control >>> plane filtering) is far more important IMO than implementing BCP38 >>> when >>> much >>> of attack traffic comes from legitimate IP sources anyway (see >>> botnets). >> >> >> I'm sorry, but nonsense statements such as these burn the blood. >> Sure, yes, >> protecting yourself is so much more important than protecting >> anyone else. >> >> Anyone else want to stand up and join the "I am an asshole" club? >> >> -- >> Jo Rhett >> Net Consonance : consonant endings by net philanthropy, open source >> and >> other randomness >> >> >> >> > -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From pauldotwall at gmail.com Thu Sep 4 12:03:47 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Thu, 4 Sep 2008 13:03:47 -0400 Subject: Force10 Gear - Opinions In-Reply-To: References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808260026g1b1b7e97u64f7b3778e52ea4f@mail.gmail.com> <1AE55697-DD7B-4721-8FC1-610524A283B8@netconsonance.com> <620fd17c0809032045h3bf1f470mca541f8b8a26f3da@mail.gmail.com> Message-ID: <620fd17c0809041003g526167fatfde003eff92af9d5@mail.gmail.com> On Thu, Sep 4, 2008 at 12:36 PM, Jo Rhett wrote: >>>> Linksys, D-Link, SMC, etc are able to pull it off on the layer 3 >>>> switches sold at Fry's for a couple benjamins a pop. :) >>> > >> I am. All of these boxes can forward packets at line rate, and list >> for a fraction of the price of the Force 10 S-Series. > > > You and I (and any real network operator) must have different definitions of > "forward at line rate". "forwards a gig-e full of 64 byte packets, random src/dst, when you hook a smartbits/ixia up to it" is mine. What's yours? Mind you, this is probably one of the more useless metrics for vendor selection these days, and nobody has a major problem with it. Drive Slow, Paul Wall From patrick at ianai.net Thu Sep 4 12:05:16 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 4 Sep 2008 13:05:16 -0400 Subject: BCP38 dismissal In-Reply-To: <2EB68782-AF2E-4E5E-8194-43A4C355E302@netconsonance.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> <2EB68782-AF2E-4E5E-8194-43A4C355E302@netconsonance.com> Message-ID: On Sep 4, 2008, at 12:52 PM, Jo Rhett wrote: > Count you which way? You seem to agree with me. Everyone should be > doing both, not discounting BCP38 because they aren't seeing an > attack right now. No one sees attacks that BCP38 would stop? Wow, I thought things like the Kaminsky bug were big news. I guess all that was for nothing? (Yes, I am being sarcastic. Anyone who thinks attacks which BCP 38 would stop are not happening in the wild is .. I believe the phrase used was "confused and misinformed".) -- TTFN, patrick > On Sep 4, 2008, at 9:50 AM, John C. A. Bambenek wrote: >> Count me in. >> >> There is no reason to limit our defenses to the one thing that we >> think is important at one instance in time... attackers change and >> adapt and multimodal defense is simply good policy. >> >> On Thu, Sep 4, 2008 at 11:45 AM, Jo Rhett >> wrote: >>> On Sep 4, 2008, at 7:24 AM, James Jun wrote: >>>> >>>> Indeed... In today's internet, protecting your own box (cp- >>>> policer/control >>>> plane filtering) is far more important IMO than implementing >>>> BCP38 when >>>> much >>>> of attack traffic comes from legitimate IP sources anyway (see >>>> botnets). >>> >>> >>> I'm sorry, but nonsense statements such as these burn the blood. >>> Sure, yes, >>> protecting yourself is so much more important than protecting >>> anyone else. >>> >>> Anyone else want to stand up and join the "I am an asshole" club? >>> >>> -- >>> Jo Rhett >>> Net Consonance : consonant endings by net philanthropy, open >>> source and >>> other randomness >>> >>> >>> >>> >> > > -- > Jo Rhett > Net Consonance : consonant endings by net philanthropy, open source > and other randomness > > > From pauldotwall at gmail.com Thu Sep 4 12:07:34 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Thu, 4 Sep 2008 13:07:34 -0400 Subject: Force10 Gear - Opinions In-Reply-To: <932F4ABF-B1B4-46FF-8155-E799044E3697@netconsonance.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <932F4ABF-B1B4-46FF-8155-E799044E3697@netconsonance.com> Message-ID: <620fd17c0809041007i6d494637tf9017377370cac68@mail.gmail.com> On Thu, Sep 4, 2008 at 12:40 PM, Jo Rhett wrote: > You added a third SFM3 which has no place to go in this chassis. No, I did not. I did, however, list it as a point of reference for a-la-carte analysis. > So $52,500 versus $62,240 for the Cisco. No, $65000.00 vs $62240.00. > Then you need to add recertify cost, which isn't cheap. And given that you > can purchase Force10 stuff *NEW* at 60% discount, you're pitting new against > used for similar prices. Yes and no. Level3 might have an aversion to running random refurbs in production (just using them as an example, they also might not :). Smaller hosting or SP shop represented on the list, "not so much". And 60 points off Cisco is possible, even for small shops with some negotiating ability. Drive Slow, Paul Wall From jrhett at netconsonance.com Thu Sep 4 12:10:19 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 4 Sep 2008 10:10:19 -0700 Subject: Force10 Gear - Opinions In-Reply-To: <620fd17c0809041003g526167fatfde003eff92af9d5@mail.gmail.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808260026g1b1b7e97u64f7b3778e52ea4f@mail.gmail.com> <1AE55697-DD7B-4721-8FC1-610524A283B8@netconsonance.com> <620fd17c0809032045h3bf1f470mca541f8b8a26f3da@mail.gmail.com> <620fd17c0809041003g526167fatfde003eff92af9d5@mail.gmail.com> Message-ID: On Sep 4, 2008, at 10:03 AM, Paul Wall wrote: >> You and I (and any real network operator) must have different >> definitions of >> "forward at line rate". > > "forwards a gig-e full of 64 byte packets, random src/dst, when you > hook a smartbits/ixia up to it" is mine. What's yours? Forwards a mixed bag of small and large packets from tens of thousands of streams (not random) 1. at sub-millisecond latency 2. no packet loss at full line rate on multiple ports 3. deals appropriately with multiple ports at full line rate leading to a single port And finally, is responsive to operator control even when full line rate is directed at switch itself. Note the "not random" comment. People love to use the random feature of ixia/etc but it rarely displays actual performance in a production network. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From james at jdfogg.com Thu Sep 4 12:14:39 2008 From: james at jdfogg.com (james) Date: Thu, 04 Sep 2008 12:14:39 -0500 Subject: BCP38 dismissal Message-ID: <48c0177f.2fd.8d0.15136@jdfogg.com> > On Sep 4, 2008, at 7:24 AM, James Jun wrote: > > Indeed... In today's internet, protecting your own box > > (cp-policer/ control > > plane filtering) is far more important IMO than > > implementing BCP38 when much > > of attack traffic comes from legitimate IP sources > > anyway (see botnets). > > > I'm sorry, but nonsense statements such as these burn the > blood. Sure, yes, protecting yourself is so much more > important than protecting anyone else. > > Anyone else want to stand up and join the "I am an > asshole" club? OK, I'm an asshole. I'm sure BCP38 can prove to be useful, but I'll never drop my shields. I guess being an asshole is not so bad given that I have plenty of company. From pauldotwall at gmail.com Thu Sep 4 12:14:20 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Thu, 4 Sep 2008 13:14:20 -0400 Subject: BCP38 dismissal In-Reply-To: <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> Message-ID: <620fd17c0809041014n26cdcebo784c6de2f932e149@mail.gmail.com> On Thu, Sep 4, 2008 at 12:45 PM, Jo Rhett wrote: > I'm sorry, but nonsense statements such as these burn the blood. Sure, yes, > protecting yourself is so much more important than protecting anyone else. > > Anyone else want to stand up and join the "I am an asshole" club? uRPF is important. But all the uRPF in the world won't protect you against a little tcp/{22,23,179} SYN aimed at your Force 10 box. Ya know what I mean? Paul Wall From jrhett at netconsonance.com Thu Sep 4 12:12:22 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 4 Sep 2008 10:12:22 -0700 Subject: BCP38 dismissal In-Reply-To: References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> <2EB68782-AF2E-4E5E-8194-43A4C355E302@netconsonance.com> Message-ID: <31213FFA-14E1-4EAD-8A13-E07D022ECFED@netconsonance.com> Patrick, it would appear that you are insulting me by your choice of quotes but from content one would assume you agree with me. Perhaps next time quote the idiot that said attacks BCP38 would stop don't happen any more? (top posted because the thread is already confused) On Sep 4, 2008, at 10:05 AM, Patrick W. Gilmore wrote: > On Sep 4, 2008, at 12:52 PM, Jo Rhett wrote: > >> Count you which way? You seem to agree with me. Everyone should >> be doing both, not discounting BCP38 because they aren't seeing an >> attack right now. > > No one sees attacks that BCP38 would stop? > > Wow, I thought things like the Kaminsky bug were big news. I guess > all that was for nothing? > > (Yes, I am being sarcastic. Anyone who thinks attacks which BCP 38 > would stop are not happening in the wild is .. I believe the phrase > used was "confused and misinformed".) > > -- > TTFN, > patrick > > > >> On Sep 4, 2008, at 9:50 AM, John C. A. Bambenek wrote: >>> Count me in. >>> >>> There is no reason to limit our defenses to the one thing that we >>> think is important at one instance in time... attackers change and >>> adapt and multimodal defense is simply good policy. >>> >>> On Thu, Sep 4, 2008 at 11:45 AM, Jo Rhett >>> wrote: >>>> On Sep 4, 2008, at 7:24 AM, James Jun wrote: >>>>> >>>>> Indeed... In today's internet, protecting your own box (cp- >>>>> policer/control >>>>> plane filtering) is far more important IMO than implementing >>>>> BCP38 when >>>>> much >>>>> of attack traffic comes from legitimate IP sources anyway (see >>>>> botnets). >>>> >>>> >>>> I'm sorry, but nonsense statements such as these burn the blood. >>>> Sure, yes, >>>> protecting yourself is so much more important than protecting >>>> anyone else. >>>> >>>> Anyone else want to stand up and join the "I am an asshole" club? >>>> >>>> -- >>>> Jo Rhett >>>> Net Consonance : consonant endings by net philanthropy, open >>>> source and >>>> other randomness >>>> >>>> >>>> >>>> >>> >> >> -- >> Jo Rhett >> Net Consonance : consonant endings by net philanthropy, open source >> and other randomness >> >> >> > > -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Thu Sep 4 12:14:50 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 4 Sep 2008 10:14:50 -0700 Subject: Force10 Gear - Opinions In-Reply-To: <620fd17c0809041007i6d494637tf9017377370cac68@mail.gmail.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <932F4ABF-B1B4-46FF-8155-E799044E3697@netconsonance.com> <620fd17c0809041007i6d494637tf9017377370cac68@mail.gmail.com> Message-ID: <9DEC696A-A850-46DE-BBB9-13E6C8B4CBAE@netconsonance.com> On Sep 4, 2008, at 10:07 AM, Paul Wall wrote: > On Thu, Sep 4, 2008 at 12:40 PM, Jo Rhett > wrote: >> You added a third SFM3 which has no place to go in this chassis. > > No, I did not. I did, however, list it as a point of reference for > a-la-carte analysis. > >> So $52,500 versus $62,240 for the Cisco. > > No, $65000.00 vs $62240.00. I have a current spreadsheet here, and trust me your math went wrong somewhere. A completely full chassis is only a bit more than what you are quoting (at list) and the chassis itself is practically free. But no, I'm not going to redo the math. I'm not a F10 salesperson and I have much more important things to do right now. (not trying to be rude, just seriously...) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Thu Sep 4 12:18:28 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 4 Sep 2008 10:18:28 -0700 Subject: BCP38 dismissal In-Reply-To: <620fd17c0809041014n26cdcebo784c6de2f932e149@mail.gmail.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> <620fd17c0809041014n26cdcebo784c6de2f932e149@mail.gmail.com> Message-ID: <9058D9BE-9276-4BBF-8EF7-6CAAD62524C4@netconsonance.com> On Sep 4, 2008, at 10:14 AM, Paul Wall wrote: > On Thu, Sep 4, 2008 at 12:45 PM, Jo Rhett > wrote: >> I'm sorry, but nonsense statements such as these burn the blood. >> Sure, yes, >> protecting yourself is so much more important than protecting >> anyone else. >> >> Anyone else want to stand up and join the "I am an asshole" club? > > uRPF is important. But all the uRPF in the world won't protect you > against a little tcp/{22,23,179} SYN aimed at your Force 10 box. > > Ya know what I mean? No. Because our F10s aren't suspectible to that, period. I think this whole "control panel policing" is flat out wrong, but honestly to argue that point I'd have to do some research into what Cisco is doing these days (never had most of the good anti-dos and flood-control stuff F10 has last time I looked) and frankly, it's not within my scope of work so I left that alone. The focus of my comment was on the "BCP38 isn't important", because *THAT* is something that causes grief for me (and everyone) in the day job. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Thu Sep 4 12:20:07 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 4 Sep 2008 10:20:07 -0700 Subject: BCP38 dismissal In-Reply-To: <48c0177f.2fd.8d0.15136@jdfogg.com> References: <48c0177f.2fd.8d0.15136@jdfogg.com> Message-ID: On Sep 4, 2008, at 10:14 AM, james wrote: > OK, I'm an asshole. I'm sure BCP38 can prove to be useful > I guess being an asshole is not so bad given that I have > plenty of company. It is unfortunately true that you do have lots of company. If I could get away with dropping all routes from people like you I'd be a lot happier. (and we'd all be a lot safer) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From patrick at ianai.net Thu Sep 4 12:21:32 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 4 Sep 2008 13:21:32 -0400 Subject: BCP38 dismissal In-Reply-To: <48c0177f.2fd.8d0.15136@jdfogg.com> References: <48c0177f.2fd.8d0.15136@jdfogg.com> Message-ID: <5C0CAC21-1D06-492B-AEEE-442BD8B16608@ianai.net> On Sep 4, 2008, at 1:14 PM, james wrote: >> On Sep 4, 2008, at 7:24 AM, James Jun wrote: >>> Indeed... In today's internet, protecting your own box >>> (cp-policer/ control >>> plane filtering) is far more important IMO than >>> implementing BCP38 when much >>> of attack traffic comes from legitimate IP sources >>> anyway (see botnets). >> >> >> I'm sorry, but nonsense statements such as these burn the >> blood. Sure, yes, protecting yourself is so much more >> important than protecting anyone else. >> >> Anyone else want to stand up and join the "I am an >> asshole" club? > > > OK, I'm an asshole. > I'm sure BCP38 can prove to be useful, but I'll never drop > my shields. I am pretty certain James was not suggesting you "drop your shields". My understanding is he thinks anyone who -only- protects their own router CPUs, but lets random packets leave their network with fake source addresses for other networks is an ass hole (shields up or not). Assuming that is what he meant, I agree with him. Now, would you care to reiterate your ass-hole-ness and admit to 10s of 1000s of your closest friends that you let your users attack them (and me!) in undetectable ways, make things like the Kaminsky DNS vulnerability possible, etc.? -- TTFN, patrick From rubensk at gmail.com Thu Sep 4 12:23:40 2008 From: rubensk at gmail.com (Rubens Kuhl Jr.) Date: Thu, 4 Sep 2008 14:23:40 -0300 Subject: Force10 Gear - Opinions In-Reply-To: <620fd17c0809041007i6d494637tf9017377370cac68@mail.gmail.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <932F4ABF-B1B4-46FF-8155-E799044E3697@netconsonance.com> <620fd17c0809041007i6d494637tf9017377370cac68@mail.gmail.com> Message-ID: <6bb5f5b10809041023o5b844418w47c0cbe4a1c33826@mail.gmail.com> > > And 60 points off Cisco is possible, even for small shops with some > negotiating ability. That's not our experience; it seems that BUs protecting margins talk louder than the sales guys, so when it reaches discounts like that, even because of lack of adequate product from Cisco (lower gear can't handle it, big gear is too expensive), the competition winning is worse to Cisco but better to the BU numbers, so they leave it to that. Rubens From james at jdfogg.com Thu Sep 4 12:26:56 2008 From: james at jdfogg.com (james) Date: Thu, 04 Sep 2008 12:26:56 -0500 Subject: BCP38 dismissal Message-ID: <48c01a60.279.518.6855@jdfogg.com> > On Sep 4, 2008, at 10:14 AM, james wrote: > > OK, I'm an asshole. I'm sure BCP38 can prove to be > > useful I guess being an asshole is not so bad given that > > I have plenty of company. > > > It is unfortunately true that you do have lots of company. > If I could get away with dropping all routes from > people like you I'd be a lot happier. (and we'd all be > a lot safer) Let me put this another way. Calling people names doesn't promote your interests. It starts flame wars. From deleskie at gmail.com Thu Sep 4 12:37:44 2008 From: deleskie at gmail.com (jim deleskie) Date: Thu, 4 Sep 2008 14:37:44 -0300 Subject: Force10 Gear - Opinions In-Reply-To: <6bb5f5b10809041023o5b844418w47c0cbe4a1c33826@mail.gmail.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <932F4ABF-B1B4-46FF-8155-E799044E3697@netconsonance.com> <620fd17c0809041007i6d494637tf9017377370cac68@mail.gmail.com> <6bb5f5b10809041023o5b844418w47c0cbe4a1c33826@mail.gmail.com> Message-ID: I've recently seen Cisco, loose an approx ~$1MM deal at an all Cisco shop to Force10 Cisco wouldn't better mid 40's discount. On Thu, Sep 4, 2008 at 2:23 PM, Rubens Kuhl Jr. wrote: >> >> And 60 points off Cisco is possible, even for small shops with some >> negotiating ability. > > That's not our experience; it seems that BUs protecting margins talk > louder than the sales guys, so when it reaches discounts like that, > even because of lack of adequate product from Cisco (lower gear can't > handle it, big gear is too expensive), the competition winning is > worse to Cisco but better to the BU numbers, so they leave it to that. > > Rubens > > From patrick at ianai.net Thu Sep 4 12:41:41 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 4 Sep 2008 13:41:41 -0400 Subject: BCP38 dismissal In-Reply-To: <31213FFA-14E1-4EAD-8A13-E07D022ECFED@netconsonance.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> <2EB68782-AF2E-4E5E-8194-43A4C355E302@netconsonance.com> <31213FFA-14E1-4EAD-8A13-E07D022ECFED@netconsonance.com> Message-ID: <881D1DF1-E51D-402A-BE7D-55091774492D@ianai.net> On Sep 4, 2008, at 1:12 PM, Jo Rhett wrote: > Patrick, it would appear that you are insulting me by your choice of > quotes but from content one would assume you agree with me. Perhaps > next time quote the idiot that said attacks BCP38 would stop don't > happen any more? > (top posted because the thread is already confused) Sorry for the confusion. Yes, I am a BCP38 evangelist. I apologize if it came across wrong. -- TTFN, patrick > On Sep 4, 2008, at 10:05 AM, Patrick W. Gilmore wrote: >> On Sep 4, 2008, at 12:52 PM, Jo Rhett wrote: >> >>> Count you which way? You seem to agree with me. Everyone should >>> be doing both, not discounting BCP38 because they aren't seeing an >>> attack right now. >> >> No one sees attacks that BCP38 would stop? >> >> Wow, I thought things like the Kaminsky bug were big news. I guess >> all that was for nothing? >> >> (Yes, I am being sarcastic. Anyone who thinks attacks which BCP 38 >> would stop are not happening in the wild is .. I believe the phrase >> used was "confused and misinformed".) >> >> -- >> TTFN, >> patrick >> >> >> >>> On Sep 4, 2008, at 9:50 AM, John C. A. Bambenek wrote: >>>> Count me in. >>>> >>>> There is no reason to limit our defenses to the one thing that we >>>> think is important at one instance in time... attackers change and >>>> adapt and multimodal defense is simply good policy. >>>> >>>> On Thu, Sep 4, 2008 at 11:45 AM, Jo Rhett >>>> wrote: >>>>> On Sep 4, 2008, at 7:24 AM, James Jun wrote: >>>>>> >>>>>> Indeed... In today's internet, protecting your own box (cp- >>>>>> policer/control >>>>>> plane filtering) is far more important IMO than implementing >>>>>> BCP38 when >>>>>> much >>>>>> of attack traffic comes from legitimate IP sources anyway (see >>>>>> botnets). >>>>> >>>>> >>>>> I'm sorry, but nonsense statements such as these burn the >>>>> blood. Sure, yes, >>>>> protecting yourself is so much more important than protecting >>>>> anyone else. >>>>> >>>>> Anyone else want to stand up and join the "I am an asshole" club? >>>>> >>>>> -- >>>>> Jo Rhett >>>>> Net Consonance : consonant endings by net philanthropy, open >>>>> source and >>>>> other randomness >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> -- >>> Jo Rhett >>> Net Consonance : consonant endings by net philanthropy, open >>> source and other randomness >>> >>> >>> >> >> > > -- > Jo Rhett > Net Consonance : consonant endings by net philanthropy, open source > and other randomness > > From ghankins at mindspring.com Thu Sep 4 13:12:56 2008 From: ghankins at mindspring.com (Greg Hankins) Date: Thu, 4 Sep 2008 14:12:56 -0400 Subject: BCP38 dismissal In-Reply-To: <620fd17c0809041014n26cdcebo784c6de2f932e149@mail.gmail.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> <620fd17c0809041014n26cdcebo784c6de2f932e149@mail.gmail.com> Message-ID: <20080904181256.GA20349@force10networks.com> On Thu, Sep 04, 2008 at 01:14:20PM -0400, Paul Wall wrote: >On Thu, Sep 4, 2008 at 12:45 PM, Jo Rhett wrote: >> I'm sorry, but nonsense statements such as these burn the blood. Sure, yes, >> protecting yourself is so much more important than protecting anyone else. >> >> Anyone else want to stand up and join the "I am an asshole" club? > >uRPF is important. But all the uRPF in the world won't protect you >against a little tcp/{22,23,179} SYN aimed at your Force 10 box. > >Ya know what I mean? Hey Paul, would you be able to demonstrate this problem? I'd like to see it so that we can investigate and fix it. You are correct that the first generation of E-Series hardware (EtherScale) had little control plane protection. The current E-Series hardware (TeraScale) has a completely different architecture that rate limits, queues and filters all packets destined to the control plane. Greg* (* I am currently employed by Force10.) -- Greg Hankins From jkinz at kinz.org Thu Sep 4 13:57:30 2008 From: jkinz at kinz.org (Jeff Kinz) Date: Thu, 4 Sep 2008 14:57:30 -0400 Subject: ingress SMTP In-Reply-To: <60044.210.54.216.162.1220493708.squirrel@webmail.blakjak.net> References: <60044.210.54.216.162.1220493708.squirrel@webmail.blakjak.net> Message-ID: <20080904185730.GC14670@redline.kinz.org> On Thu, Sep 04, 2008 at 02:01:48PM +1200, Mark Foster wrote: > So in terms of the OP, > I don't see why joe-user on a dynamic-IP home connection should need the > ability to use port 25 to talk to anywhere but their local ISP SMTP server > on a normal basis[1]. Whats a normal basis? My Home ISP won't let me send to more than 200 (or so) email addresses per day. If I used my ISP's email system I would constantly be losing my email service due to hitting the limit. I do the field scheduling for my local town soccer league. [Never volunteer! :-) ] So when I send a few announcements out to coaches, referees and administrators, I hit that limit and get my email shutoff for two days or so. I eventually switched to MailHop at DynDNS (smtp auth) I would have used port 25 but our ISP has begun blocking outbound port 25 nationwide, due to large amount of outbound spam from their customers. :-) > Theyre not doing MX lookups so theyre not going > direct to remote MTAs[2]. Regardless of where they got the mail _from_, > the outbound mail should be via SMTP to their local SMTP server.[3] > > If you separate inbound (pop3) and outbound (smtp) mail delivery in your > thinking you can start to make sense of things (from a users perspective). > This is always the tack i've taken when trying to educate users about why > their email outbound doesn't work when theyre moving from ISP to ISP. > (At which point you offer them your authenticated-another-way service, > such as 587 with SMTP auth). > > [1] Customers with a specific need to do so should have the means to > opt-out. I believe most of the ISPs in NZ who block 25-outbound from > clients also offer this option. > > [2] Customers doing MX lookups are either drones or people with mail > servers at home. The former are obviously the target of the block. The > latter are likely going to be any one of: > > - Blocked by SORBS or similar as a dynamic IP > - Running a mail server in breach of AUP > - On a fixed IP and (theoretically) capable of securing their system and > not being a drone or open mail relay (and being traceable via their ISP). > > [3] Note also [2]. Outbound mail is associated with your ISP and their > SMTP service. Has nothing to do with inbound mail. Nothing. Nada. Zip. > > Or doesn't the rest of the world think like this? > > Mark. > > PS: It occurs to me that SPF has an influence here, if you're aggressively > using it then you should also be offering alternatives to Port 25 SMTP. > IMHO. > -- From ge at linuxbox.org Thu Sep 4 14:38:33 2008 From: ge at linuxbox.org (Gadi Evron) Date: Thu, 4 Sep 2008 14:38:33 -0500 (CDT) Subject: BCP38 dismissal In-Reply-To: <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> Message-ID: On Thu, 4 Sep 2008, Jo Rhett wrote: > On Sep 4, 2008, at 7:24 AM, James Jun wrote: >> Indeed... In today's internet, protecting your own box (cp-policer/control >> plane filtering) is far more important IMO than implementing BCP38 when >> much >> of attack traffic comes from legitimate IP sources anyway (see botnets). > > > I'm sorry, but nonsense statements such as these burn the blood. Sure, yes, > protecting yourself is so much more important than protecting anyone else. > > Anyone else want to stand up and join the "I am an asshole" club? "I'm an a??hole!" :o) (lotsa folks get corporate "bad words" filters, here). Seriously though, everyone should take care of their own end first. The problem is Jo doesn't seem to be in the loopon attacks from recent years, but I am unsure he would change his mind if he was/ > -- > Jo Rhett > Net Consonance : consonant endings by net philanthropy, open source and other > randomness > > > From michael.dillon at bt.com Thu Sep 4 15:12:32 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 4 Sep 2008 21:12:32 +0100 Subject: BCP38 dismissal In-Reply-To: <881D1DF1-E51D-402A-BE7D-55091774492D@ianai.net> Message-ID: > Sorry for the confusion. ^^^^^ > > Yes, I am a BCP38 evangelist. I apologize if it came across wrong. ^^^^^^^^^^^ OK, Patrick is setting an example. Could we all do likewise and get back to a civil conversation? > TTFN, > patrick Kudos for a good example. People on this list should not be surprised that other list members do not know everything. This doesn't make them idiots, it just means that there is an opportunity for you to politely educate them and hopefully gain a few converts to whatever cause you are championing. --Michael Dillon From patrick at ianai.net Thu Sep 4 15:30:44 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 4 Sep 2008 16:30:44 -0400 Subject: BCP38 dismissal In-Reply-To: References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> Message-ID: <3861BD57-759F-4EE5-A274-DBCDE7F7485B@ianai.net> On Sep 4, 2008, at 3:38 PM, Gadi Evron wrote: > On Thu, 4 Sep 2008, Jo Rhett wrote: >> On Sep 4, 2008, at 7:24 AM, James Jun wrote: >>> Indeed... In today's internet, protecting your own box (cp-policer/ >>> control >>> plane filtering) is far more important IMO than implementing BCP38 >>> when much >>> of attack traffic comes from legitimate IP sources anyway (see >>> botnets). >> >> >> I'm sorry, but nonsense statements such as these burn the blood. >> Sure, yes, protecting yourself is so much more important than >> protecting anyone else. >> >> Anyone else want to stand up and join the "I am an asshole" club? > > "I'm an a??hole!" :o) > (lotsa folks get corporate "bad words" filters, here). > > Seriously though, everyone should take care of their own end first. > The problem is Jo doesn't seem to be in the loopon attacks from > recent years, but I am unsure he would change his mind if he was/ Gadi, Do you really want to suggest to people that they not implement BCP38? -- TTFN, patrick From jrhett at netconsonance.com Thu Sep 4 16:16:07 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 4 Sep 2008 14:16:07 -0700 Subject: BCP38 dismissal In-Reply-To: References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> Message-ID: <315BC48A-E42A-48B5-84F6-664395D95A46@netconsonance.com> On Sep 4, 2008, at 12:38 PM, Gadi Evron wrote: > Seriously though, everyone should take care of their own end first. > The problem is Jo doesn't seem to be in the loopon attacks from > recent years, but I am unsure he would change his mind if he was/ Nice going, Gadi -- let's insult someone who does a good job of protecting your network from his customers. I spend at least 8 hours a week tracking down attacks originating from non-BCP38 networks. This is still a real problem, and the idea that BCP-38 is some fad that is irrelevant now ... I have no words for this kind of idiocy. Everyone should be doing BCP-38. Why don't you apply this to your network, instead of sitting around insulting people for your incorrect assumptions about their job? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From ge at linuxbox.org Thu Sep 4 16:46:59 2008 From: ge at linuxbox.org (Gadi Evron) Date: Thu, 4 Sep 2008 16:46:59 -0500 (CDT) Subject: BCP38 dismissal In-Reply-To: <3861BD57-759F-4EE5-A274-DBCDE7F7485B@ianai.net> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> <3861BD57-759F-4EE5-A274-DBCDE7F7485B@ianai.net> Message-ID: On Thu, 4 Sep 2008, Patrick W. Gilmore wrote: > On Sep 4, 2008, at 3:38 PM, Gadi Evron wrote: >> On Thu, 4 Sep 2008, Jo Rhett wrote: >>> On Sep 4, 2008, at 7:24 AM, James Jun wrote: >>>> Indeed... In today's internet, protecting your own box (cp-policer/ >>>> control >>>> plane filtering) is far more important IMO than implementing BCP38 when >>>> much >>>> of attack traffic comes from legitimate IP sources anyway (see botnets). >>> >>> >>> I'm sorry, but nonsense statements such as these burn the blood. Sure, >>> yes, protecting yourself is so much more important than protecting anyone >>> else. >>> >>> Anyone else want to stand up and join the "I am an asshole" club? >> >> "I'm an a??hole!" :o) >> (lotsa folks get corporate "bad words" filters, here). >> >> Seriously though, everyone should take care of their own end first. The >> problem is Jo doesn't seem to be in the loopon attacks from recent years, >> but I am unsure he would change his mind if he was/ > > Gadi, > > Do you really want to suggest to people that they not implement BCP38? No. Thank you for calling me on not explaining well. I suggest that the guy is right. People should tajke care of their security first before going out and shouting at the world. That said, I also state that he is probably not in touch with what's been going on in the past few years. Meaning, botnets *do* use spoofing, and DNS amplification attacks. The threat is not "theoretical" for a few years now and he may simply not be in on it. As to preaching BCP38, well... it's not an easy leap of thought to make, that your security is tied into the state of security of a box sitting half-way around the world. But that's the case. Gadi. > -- > TTFN, > patrick > > From ge at linuxbox.org Thu Sep 4 16:56:39 2008 From: ge at linuxbox.org (Gadi Evron) Date: Thu, 4 Sep 2008 16:56:39 -0500 (CDT) Subject: BCP38 dismissal In-Reply-To: <315BC48A-E42A-48B5-84F6-664395D95A46@netconsonance.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> <315BC48A-E42A-48B5-84F6-664395D95A46@netconsonance.com> Message-ID: On Thu, 4 Sep 2008, Jo Rhett wrote: > On Sep 4, 2008, at 12:38 PM, Gadi Evron wrote: >> Seriously though, everyone should take care of their own end first. The >> problem is Jo doesn't seem to be in the loopon attacks from recent years, >> but I am unsure he would change his mind if he was/ > > > Nice going, Gadi -- let's insult someone who does a good job of protecting > your network from his customers. > > I spend at least 8 hours a week tracking down attacks originating from > non-BCP38 networks. This is still a real problem, and the idea that BCP-38 > is some fad that is irrelevant now ... I have no words for this kind of > idiocy. Everyone should be doing BCP-38. Why don't you apply this to your > network, instead of sitting around insulting people for your incorrect > assumptions about their job? I apologize for making an incorrect assumption and apparently insulting you. My assumption was based on the threading in the email I replied to, as what you write here conpletely contradicts what was written there. So, we all support BCP38 and nothing really changed from the last time we all had this discussion about why most of us don't use it. > -- > Jo Rhett > Net Consonance : consonant endings by net philanthropy, open source and other > randomness > > From jrhett at netconsonance.com Thu Sep 4 17:10:48 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 4 Sep 2008 15:10:48 -0700 Subject: BCP38 dismissal In-Reply-To: References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> <315BC48A-E42A-48B5-84F6-664395D95A46@netconsonance.com> Message-ID: <8A5FEE72-B8FC-4B42-B8BA-80F170741595@netconsonance.com> On Sep 4, 2008, at 2:56 PM, Gadi Evron wrote: > I apologize for making an incorrect assumption and apparently > insulting you. > My assumption was based on the threading in the email I replied to, > as what you write here conpletely contradicts what was written there. Yeah, I think the threading was getting confused quite a bit. > So, we all support BCP38 and nothing really changed from the last > time we all had this discussion about why most of us don't use it. On that you'll have to speak for yourself. We have it on every customer port ;-) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From ge at linuxbox.org Thu Sep 4 17:22:18 2008 From: ge at linuxbox.org (Gadi Evron) Date: Thu, 4 Sep 2008 17:22:18 -0500 (CDT) Subject: BCP38 dismissal In-Reply-To: <8A5FEE72-B8FC-4B42-B8BA-80F170741595@netconsonance.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> <315BC48A-E42A-48B5-84F6-664395D95A46@netconsonance.com> <8A5FEE72-B8FC-4B42-B8BA-80F170741595@netconsonance.com> Message-ID: On Thu, 4 Sep 2008, Jo Rhett wrote: > On Sep 4, 2008, at 2:56 PM, Gadi Evron wrote: >> I apologize for making an incorrect assumption and apparently insulting >> you. >> My assumption was based on the threading in the email I replied to, as what >> you write here conpletely contradicts what was written there. > > Yeah, I think the threading was getting confused quite a bit. > >> So, we all support BCP38 and nothing really changed from the last time we >> all had this discussion about why most of us don't use it. > > > On that you'll have to speak for yourself. We have it on every customer port > ;-) Now that is interesting. Can you share a bit about you rimplementation hardships, costs, customer complaints, etc? Gadi. > > -- > Jo Rhett > Net Consonance : consonant endings by net philanthropy, open source and other > randomness > > From william.allen.simpson at gmail.com Thu Sep 4 17:36:33 2008 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Thu, 04 Sep 2008 18:36:33 -0400 Subject: BCP38 dismissal In-Reply-To: <315BC48A-E42A-48B5-84F6-664395D95A46@netconsonance.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> <315BC48A-E42A-48B5-84F6-664395D95A46@netconsonance.com> Message-ID: <48C062F1.6060302@gmail.com> Jo Rhett wrote: > On Sep 4, 2008, at 12:38 PM, Gadi Evron wrote: >> Seriously though, everyone should take care of their own end first. >> The problem is Jo doesn't seem to be in the loopon attacks from recent >> years, but I am unsure he would change his mind if he was/ > > > Nice going, Gadi -- let's insult someone who does a good job of > protecting your network from his customers. > Reminder: Gadi isn't a native English speaker. I understood "Take care of their own end first" to mean "please do BCP38" -- it polices your "own" end. > I spend at least 8 hours a week tracking down attacks originating from > non-BCP38 networks. This is still a real problem, and the idea that > BCP-38 is some fad that is irrelevant now ... I have no words for this > kind of idiocy. Everyone should be doing BCP-38. ... > Hopefully, we all agree! That's why it's been a "Best Current Practice" for a decade or so.... From mtinka at globaltransit.net Thu Sep 4 17:52:18 2008 From: mtinka at globaltransit.net (Mark Tinka) Date: Fri, 5 Sep 2008 06:52:18 +0800 Subject: uRPF In-Reply-To: References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <200809041634.38615.mtinka@globaltransit.net> Message-ID: <200809050652.26002.mtinka@globaltransit.net> On Friday 05 September 2008 00:42:12 Jo Rhett wrote: > So you are talking single site, or single peering > location? Not quite. We do this at every PoP/location where we peer and/or buy transit. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: From marka at isc.org Thu Sep 4 18:04:11 2008 From: marka at isc.org (Mark Andrews) Date: Fri, 5 Sep 2008 09:04:11 +1000 (EST) Subject: BCP38 dismissal In-Reply-To: <8A5FEE72-B8FC-4B42-B8BA-80F170741595@netconsonance.com> Message-ID: <200809042304.m84N4BxE095136@drugs.dv.isc.org> >> So, we all support BCP38 and nothing really changed from the last >> time we all had this discussion about why most of us don't use it. > > >On that you'll have to speak for yourself. We have it on every >customer port ;-) I hope you *also* have it on your NOC and everywhere else that it is practical to have it. Every machine can potentially be taken over and used as a launch point. Mark >-- >Jo Rhett >Net Consonance : consonant endings by net philanthropy, open source >and other randomness From blakjak at blakjak.net Thu Sep 4 18:33:54 2008 From: blakjak at blakjak.net (Mark Foster) Date: Fri, 5 Sep 2008 11:33:54 +1200 (NZST) Subject: ingress SMTP In-Reply-To: <20080904185730.GC14670@redline.kinz.org> References: <60044.210.54.216.162.1220493708.squirrel@webmail.blakjak.net> <20080904185730.GC14670@redline.kinz.org> Message-ID: <12462.119.15.0.26.1220571234.squirrel@webmail.blakjak.net> > On Thu, Sep 04, 2008 at 02:01:48PM +1200, Mark Foster wrote: >> So in terms of the OP, >> I don't see why joe-user on a dynamic-IP home connection should need the >> ability to use port 25 to talk to anywhere but their local ISP SMTP >> server >> on a normal basis[1]. > > Whats a normal basis? > > My Home ISP won't let me send to more than 200 (or so) email addresses > per day. If I used my ISP's email system I would constantly be losing > my email service due to hitting the limit. > > I do the field scheduling for my local town soccer league. > [Never volunteer! :-) ] > > So when I send a few announcements out to coaches, referees and > administrators, I hit that limit and get my email shutoff for two days > or so. I eventually switched to MailHop at DynDNS (smtp auth) > > I would have used port 25 but our ISP has begun blocking outbound > port 25 nationwide, due to large amount of outbound spam from their > customers. :-) > > *rest snipped* Is the above described limitation a common occurrance in the world-at-large? I've not heard of ISPs doing number-of-recipients-per-day limitations. I've heard of them doing number-of-recipients-per-email limitations (thus limiting large cc/bcc lists) but not total number of emails. Who's to say that there arent legitimate reasons to email a large number of people - perhaps your customers?? Certainly if my own ISP did something like that, you're quite right, i'd have to find an alternative. (Or perhaps, an alternative ISP. ) (who set the limit at 200? Can you opt-out of the limit or have it upped?) Mark. From hobbit at avian.org Thu Sep 4 18:08:21 2008 From: hobbit at avian.org (*Hobbit*) Date: Thu, 4 Sep 2008 23:08:21 +0000 (GMT) Subject: BCP here and there Message-ID: <20080904230821.A48897809@relayer.avian.org> In my mind, a suite of practices to keep one's garbage contained and not all over the neighbor's lawn is a good thing and covers many bases. RPF/BCP38 seems to be the IP level equivalent of blocking ingress SMTP and forcing delivery through outbound-only servers that check the claimed envelope and/or header senders for sanity relative to the authorized sending networks. If so many people are agreeing on BCP38, what's with the resistance about email, clearly an equally polluted swamp? Why would one not want to view the two issues as much the same problem, at different layers? And yes, I was assuming split-brained mail infrastructure to make port-25 filtering much simpler. To counter someone's counterargument, it could boil down to two ACL lines in *many* places, but clearly not all. Said two lines can come right before the one that says "permit ip my-source-only any", couldn't they?? Not in a blanket sense, of course -- these things done *where appropriate* and tuned to known requirements could vastly improve matters, but it seems that even after all these years so many of the appropriate places haven't even been touched let alone fixed. _H* From jkinz at kinz.org Thu Sep 4 19:39:19 2008 From: jkinz at kinz.org (Jeff Kinz) Date: Thu, 4 Sep 2008 20:39:19 -0400 Subject: ingress SMTP In-Reply-To: <12462.119.15.0.26.1220571234.squirrel@webmail.blakjak.net> References: <60044.210.54.216.162.1220493708.squirrel@webmail.blakjak.net> <20080904185730.GC14670@redline.kinz.org> <12462.119.15.0.26.1220571234.squirrel@webmail.blakjak.net> Message-ID: <20080905003919.GA5223@redline.kinz.org> On Fri, Sep 05, 2008 at 11:33:54AM +1200, Mark Foster wrote: > Summary: Perceived limit of 200 email addresses delivered to per day > *rest snipped* > > Is the above described limitation a common occurrance in the world-at-large? > > I've not heard of ISPs doing number-of-recipients-per-day limitations. > I've heard of them doing number-of-recipients-per-email limitations (thus > limiting large cc/bcc lists) but not total number of emails. An excellent question. I was unable, as a customer, to get a direct answer to any of my queries as to what was or wasn't allowed at all, despite multiple attempts each time it happened. After the 3rd cut-off, I cut out, so to speak. :-) All my email still travels over their network, it just doesn't get routed through their SMTP servers. > Who's to say that there arent legitimate reasons to email a large number > of people - perhaps your customers?? > > Certainly if my own ISP did something like that, you're quite right, i'd > have to find an alternative. (Or perhaps, an alternative ISP. ) > > (who set the limit at 200? Can you opt-out of the limit or have it upped?) Never found any way to, but that may only mean I didn't find the right magic combination. At least now I know my monthly gross transfer is limited to 250 GB (except in February when its only 228 GB... :-) ) Jeff Kinz. -- From joe at sumless.net Thu Sep 4 22:39:45 2008 From: joe at sumless.net (Joe Blanchard) Date: Thu, 4 Sep 2008 23:39:45 -0400 Subject: BCP IETFs and RFCs In-Reply-To: <20080904230821.A48897809@relayer.avian.org> Message-ID: <00c401c90f09$0c27ff80$1401a8c0@E520> Well at the risk of getting flammed here.. lol I don't believe there is a real clear answer here to this BCP38 debate. Great suggestions, great comments, and great what ifs. >From the old days, I always recalled ACLing non-existant scopes within my nets, again not that that is the answer, but it was a recommended practice, and when we saw non-existant spaces trying to leave one of our feeds it was quickly handled internally (i.e. killed the downstream link). As well we always had to do an internal audit of why/who/where the event took place and a remedy to it (HIPAA & SOX compliance stuff) While this thread is informative at times, I think the name calling and insults really serve no purpose to it. I recall a funny saying regarding this, opinions are like a......s, everyone has one and everyone else thinks it stinks. Doesn't mean anyones right. Agree to dis-agree and lets be on with it. Deja-vu, Wasn't there a thread about this same subject a while ago something regarding RFC2827? Might just be me. Just my 2?s Regards, -Joe Blanchard "I am Joe Blanchard and I approve this message.... lol" From bmanning at vacation.karoshi.com Fri Sep 5 00:22:27 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 5 Sep 2008 05:22:27 +0000 Subject: an effect of ignoring BCP38 In-Reply-To: References: <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> <3861BD57-759F-4EE5-A274-DBCDE7F7485B@ianai.net> Message-ID: <20080905052227.GA8309@vacation.karoshi.com.> seems that some folks in the R&E community, with institutional support from Cisco, Google, and the US NSF, are exploiting our inability to take even rudimentary steps toward providing a level of integrity in routing by teaching students that spoofing IP space is ok. This whole thing works at all because so few people use/deploy/maintain BCP-38 compliance. This was an eye-opener for me. http://www.caida.org/workshops/wide/0808/slides/measuring_reverse_paths.pdf --bill From simonw at zynet.net Fri Sep 5 03:21:17 2008 From: simonw at zynet.net (Simon Waters) Date: Fri, 5 Sep 2008 09:21:17 +0100 Subject: ingress SMTP In-Reply-To: <12462.119.15.0.26.1220571234.squirrel@webmail.blakjak.net> References: <20080904185730.GC14670@redline.kinz.org> <12462.119.15.0.26.1220571234.squirrel@webmail.blakjak.net> Message-ID: <200809050921.17516.simonw@zynet.net> On Friday 05 September 2008 00:33:54 Mark Foster wrote: > > *rest snipped* > > Is the above described limitation a common occurrance in the > world-at-large? If the ISP blocks port 25, then the ISP is taking responsibility for delivering all email sent by a user, and they have to start applying rate limits. Otherwise if they send all email from their users, all they've done is take the spam, and mix it in with the legitimate email, making spam filtering harder. Locally one of the big ISP insists you register all sender addresses with them, so all the spam from them has legitimate sender credentials. The problem is that by blocking port 25, you are basically then switching users to arbitrary per ISP rules for how to send email. This is probably good for ISPs (provides some sort of lock-in) but bad for their users. Whilst the antispam folk think it is a godsend because their block lists are smaller, it is relatively easy to block spewing IP addresses, and hard to filter when good and bad email is combined. Which is why they hate Google hiding the source IP address. This will continue until the real issue is addressed, which is the security of end user systems. From swmike at swm.pp.se Fri Sep 5 03:35:15 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 5 Sep 2008 10:35:15 +0200 (CEST) Subject: ingress SMTP In-Reply-To: <200809050921.17516.simonw@zynet.net> References: <20080904185730.GC14670@redline.kinz.org> <12462.119.15.0.26.1220571234.squirrel@webmail.blakjak.net> <200809050921.17516.simonw@zynet.net> Message-ID: On Fri, 5 Sep 2008, Simon Waters wrote: > If the ISP blocks port 25, then the ISP is taking responsibility for > delivering all email sent by a user, and they have to start applying rate > limits. MUAs should stop sending email via 25 and use 587 or equivalent instead. There is little actual reason why someone should be able to send TCP/25 SMTP email from a residential connection when most software support authenticated TCP/587 submits. We don't allow most of our residential customer base to speak SMTP TCP/25 to anywhere at all (and we have millions of them). Wish more ISPs would do the same. -- Mikael Abrahamsson email: swmike at swm.pp.se From fergdawg at netzero.net Fri Sep 5 03:36:10 2008 From: fergdawg at netzero.net (Paul Ferguson) Date: Fri, 5 Sep 2008 08:36:10 GMT Subject: SMTP rate-limits [Was: Re: ingress SMTP] Message-ID: <20080905.013610.2431.1@webmail10.vgs.untd.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Simon Waters wrote: >If the ISP blocks port 25, then the ISP is taking responsibility for delivering all email sent by a user, and they have to start applying rate limits. Otherwise if they send all email from their users, all they've done is take the spam, and mix it in with the legitimate email, making spam filtering harder. > Okay, I can understand why an ISP might want to apply SMTP rate-limits, but to clarify, I'm assuming you meant that ISPs (if they do block tcp/25 outbound to anything other than their own MTAs) need to watch for excessive SMTP utilization, which might indicate a spammer-client (?). ...as opposed to arbitrary SMTP rate-limits. Yes? - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFIwO90q1pz9mNUZTMRAneaAJwMgmIz99bPUYJ2HgUD6Zs1MOFXgQCgmsPY eUtV2bBKymWfxNwNOgWfp5w= =bdk+ -----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 blakjak at blakjak.net Fri Sep 5 04:12:03 2008 From: blakjak at blakjak.net (Mark Foster) Date: Fri, 5 Sep 2008 21:12:03 +1200 (NZST) Subject: ingress SMTP In-Reply-To: References: <20080904185730.GC14670@redline.kinz.org> <12462.119.15.0.26.1220571234.squirrel@webmail.blakjak.net> <200809050921.17516.simonw@zynet.net> Message-ID: On Fri, 5 Sep 2008, Mikael Abrahamsson wrote: > On Fri, 5 Sep 2008, Simon Waters wrote: > >> If the ISP blocks port 25, then the ISP is taking responsibility for >> delivering all email sent by a user, and they have to start applying rate >> limits. > > MUAs should stop sending email via 25 and use 587 or equivalent instead. > There is little actual reason why someone should be able to send TCP/25 SMTP > email from a residential connection when most software support authenticated > TCP/587 submits. > > We don't allow most of our residential customer base to speak SMTP TCP/25 to > anywhere at all (and we have millions of them). Wish more ISPs would do the > same. > Probably fair enough, if you as an ISP can get away with enforcing this sort of policy then so much the better. However relaying through your own ISPs 25/tcp should surely then make it relatively easy for noise to be tracked down and nailed at the source - by ISPs? (Do abuse@ desks investigate spam these days?) From cidr-report at potaroo.net Fri Sep 5 07:00:06 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 5 Sep 2008 22:00:06 +1000 (EST) Subject: BGP Update Report Message-ID: <200809051200.m85C06RD015084@wattle.apnic.net> BGP Update Report Interval: 04-Aug-08 -to- 04-Sep-08 (32 days) Observation Point: BGP Peering with AS2.0 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9583 214882 3.6% 165.2 -- SIFY-AS-IN Sify Limited 2 - AS1803 112095 1.9% 85.4 -- ICMNET-5 - Sprint 3 - AS5691 76392 1.3% 5876.3 -- MITRE-AS-5 - The MITRE Corporation 4 - AS8151 73810 1.2% 32.8 -- Uninet S.A. de C.V. 5 - AS9051 64555 1.1% 408.6 -- IDM Autonomous System 6 - AS10396 42202 0.7% 611.6 -- COQUI-NET - DATACOM CARIBE, INC. 7 - AS4538 37757 0.6% 7.5 -- ERX-CERNET-BKB China Education and Research Network Center 8 - AS17488 35000 0.6% 24.2 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 9 - AS5056 34878 0.6% 290.6 -- INS-NET-2 - Iowa Network Services 10 - AS209 33715 0.6% 6.8 -- ASN-QWEST - Qwest 11 - AS6663 32392 0.6% 286.7 -- EUROWEBRO Euroweb Romania SA 12 - AS14522 32304 0.6% 150.3 -- Satnet 13 - AS6389 32059 0.5% 7.3 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 14 - AS8866 32024 0.5% 99.5 -- BTC-AS Bulgarian Telecommunication Company Plc. 15 - AS14593 30375 0.5% 30375.0 -- BRAND-INSTITUTE - Brand Instiute, Inc. 16 - AS18231 29360 0.5% 118.4 -- EXATT-AS-AP IOL NETCOM LTD 17 - AS28194 29106 0.5% 5821.2 -- 18 - AS17974 27100 0.5% 35.6 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 19 - AS9198 26079 0.4% 118.0 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 20 - AS702 24919 0.4% 45.4 -- AS702 Verizon Business EMEA - Commercial IP service provider in Europe TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS14593 30375 0.5% 30375.0 -- BRAND-INSTITUTE - Brand Instiute, Inc. 2 - AS4184 15796 0.3% 7898.0 -- STORTEK-WHQ - Storage Technology Corporation 3 - AS29910 7719 0.1% 7719.0 -- IACP - INTL. ASSN OF CHIEF OF POLICEI 4 - AS5691 76392 1.3% 5876.3 -- MITRE-AS-5 - The MITRE Corporation 5 - AS28194 29106 0.5% 5821.2 -- 6 - AS43299 4786 0.1% 4786.0 -- TELECONTACT-AS Telecontact Ltd. 7 - AS23082 19339 0.3% 3867.8 -- MPHI - Michigan Public Health Institute 8 - AS38180 2666 0.0% 2666.0 -- ETPI-IDS-JOLLIBEE-AS-AP 6/Fth floor JOLLIBEE PLAZA, Emerald Ave. Ortigas Center Pasig City. 9 - AS30969 23682 0.4% 2368.2 -- TAN-NET TransAfrica Networks 10 - AS39748 2100 0.0% 2100.0 -- VITAS VITAS LLC 11 - AS23917 2002 0.0% 2002.0 -- BRIBIE-NET-AS-AP Bribie Island Net Multihomed, Brisbane 12 - AS9747 11687 0.2% 1460.9 -- EZINTERNET-AS-AP EZInternet Pty Ltd 13 - AS30929 1452 0.0% 1452.0 -- HUTCB Hidrotechnical Faculty - Technical University 14 - AS39794 1451 0.0% 1451.0 -- EL-KOZIENICE-AS Elektrownia Kozienice S.A. 15 - AS25321 1279 0.0% 1279.0 -- G4S-NET GROUP 4 SECURITAS Prague 16 - AS35385 1257 0.0% 1257.0 -- QOU Alquds Open University 17 - AS26276 6134 0.1% 1226.8 -- TIMKEN-USA - The Timken Company 18 - AS47348 1139 0.0% 1139.0 -- PEACE_GLOBAL Peace Global Satellite Communications Limited 19 - AS27245 2253 0.0% 1126.5 -- HEIDRICK-CHICAGO - HEIDRICK 20 - AS39105 1107 0.0% 1107.0 -- CLASS-AS SC Class Computers And Service SRL TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 192.12.120.0/24 76326 1.2% AS5691 -- MITRE-AS-5 - The MITRE Corporation 2 - 194.126.143.0/24 60803 0.9% AS9051 -- IDM Autonomous System 3 - 221.134.222.0/24 59717 0.9% AS9583 -- SIFY-AS-IN Sify Limited 4 - 12.8.7.0/24 30375 0.5% AS14593 -- BRAND-INSTITUTE - Brand Instiute, Inc. 5 - 83.228.71.0/24 28946 0.5% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 6 - 210.214.151.0/24 28609 0.5% AS9583 -- SIFY-AS-IN Sify Limited 7 - 221.128.192.0/18 26216 0.4% AS18231 -- EXATT-AS-AP IOL NETCOM LTD 8 - 72.50.96.0/20 24410 0.4% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 9 - 210.210.112.0/24 23727 0.4% AS9583 -- SIFY-AS-IN Sify Limited 10 - 221.135.80.0/24 23573 0.4% AS9583 -- SIFY-AS-IN Sify Limited 11 - 89.38.98.0/23 20865 0.3% AS6663 -- EUROWEBRO Euroweb Romania SA 12 - 221.135.251.0/24 17959 0.3% AS9583 -- SIFY-AS-IN Sify Limited 13 - 196.42.0.0/20 16891 0.3% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 14 - 195.251.5.0/24 14741 0.2% AS5408 -- GR-NET Greek Research & Technology Network, http://www.grnet.gr 15 - 203.63.26.0/24 11668 0.2% AS9747 -- EZINTERNET-AS-AP EZInternet Pty Ltd 16 - 196.27.104.0/21 11510 0.2% AS30969 -- TAN-NET TransAfrica Networks 17 - 196.27.108.0/22 11403 0.2% AS30969 -- TAN-NET TransAfrica Networks 18 - 205.162.132.0/23 10938 0.2% AS23541 -- Scarlet B.V. 19 - 89.4.131.0/24 9787 0.1% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 20 - 86.105.182.0/24 8799 0.1% AS6663 -- EUROWEBRO Euroweb Romania SA 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 Sep 5 07:00:03 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 5 Sep 2008 22:00:03 +1000 (EST) Subject: The Cidr Report Message-ID: <200809051200.m85C03MF015064@wattle.apnic.net> This report has been generated at Fri Sep 5 21:15:29 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 29-08-08 279583 172801 30-08-08 279888 172770 31-08-08 279518 171664 01-09-08 279520 171918 02-09-08 279541 172356 03-09-08 279757 172890 04-09-08 279781 171815 05-09-08 279838 172391 AS Summary 29282 Number of ASes in routing system 12381 Number of ASes announcing only one prefix 5010 Largest number of prefixes announced by an AS AS4538 : ERX-CERNET-BKB China Education and Research Network Center 88406528 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'). --- 05Sep08 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 280367 172403 107964 38.5% All ASes AS4538 5010 882 4128 82.4% ERX-CERNET-BKB China Education and Research Network Center AS6389 4294 350 3944 91.8% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS209 2917 1339 1578 54.1% ASN-QWEST - Qwest AS4755 1721 235 1486 86.3% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS6298 1974 783 1191 60.3% COX-PHX - Cox Communications Inc. AS17488 1372 297 1075 78.4% HATHWAY-NET-AP Hathway IP Over Cable Internet AS8151 1593 579 1014 63.7% Uninet S.A. de C.V. AS18566 1048 47 1001 95.5% COVAD - Covad Communications Co. AS1785 1649 676 973 59.0% AS-PAETEC-NET - PaeTec Communications, Inc. AS4323 1500 546 954 63.6% TWTC - tw telecom holdings, inc. AS22773 970 73 897 92.5% CCINET-2 - Cox Communications Inc. AS19262 945 167 778 82.3% VZGNI-TRANSIT - Verizon Internet Services Inc. AS11492 1213 505 708 58.4% CABLEONE - CABLE ONE AS2386 1561 912 649 41.6% INS-AS - AT&T Data Communications Services AS9498 676 65 611 90.4% BBIL-AP BHARTI Airtel Ltd. AS18101 715 126 589 82.4% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS6478 1140 602 538 47.2% ATT-INTERNET3 - AT&T WorldNet Services AS4808 628 152 476 75.8% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS855 592 126 466 78.7% CANET-ASN-4 - Bell Aliant AS4766 900 437 463 51.4% KIXS-AS-KR Korea Telecom AS22047 564 127 437 77.5% VTR BANDA ANCHA S.A. AS9443 521 86 435 83.5% INTERNETPRIMUS-AS-AP Primus Telecommunications AS7011 906 474 432 47.7% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS7018 1420 992 428 30.1% ATT-INTERNET4 - AT&T WorldNet Services AS24560 579 152 427 73.7% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7029 527 112 415 78.7% WINDSTREAM - Windstream Communications Inc AS4668 683 274 409 59.9% LGNET-AS-KR LG CNS AS4780 718 333 385 53.6% SEEDNET Digital United Inc. AS17676 524 148 376 71.8% GIGAINFRA BB TECHNOLOGY Corp. AS3602 450 76 374 83.1% AS3602-RTI - Rogers Telecom Inc. Total 39310 11673 27637 70.3% Top 30 total Possible Bogus Routes 24.75.116.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 24.75.160.0/19 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.245.128.0/17 AS11492 CABLEONE - CABLE ONE 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.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.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.188.0.0/16 AS3356 LEVEL3 Level 3 Communications 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.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 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 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 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 91.206.246.0/23 AS41241 TOPICT2-AS TOP-ICT2 Autonomous System 94.79.128.0/18 AS9010 DE-IESY Unitymedia Hessen GmbH 94.102.144.0/20 AS8426 CLARANET-AS ClaraNET 94.159.0.0/17 AS20731 MEGATON-AS Limited Company Megaton 95.165.192.0/19 AS12479 UNI2-AS Uni2 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 121.50.12.0/24 AS38236 121.50.13.0/24 AS38236 121.50.14.0/24 AS38236 121.50.15.0/24 AS38236 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.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.248.0/23 AS680 DFN-IP service G-WiN 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.25.240.0/21 AS3209 Arcor IP-Network 193.25.246.0/24 AS3211 Arcor Data-Network 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 - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 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.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.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.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.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.144.160.0/20 AS7296 ALCHEMYNET - Alchemy Communications, 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.220/32 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.241.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 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/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.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.127.124.0/23 AS2828 XO-AS15 - XO Communications 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.229.51.0/24 AS15211 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 rs at seastrom.com Fri Sep 5 09:32:46 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Fri, 05 Sep 2008 10:32:46 -0400 Subject: [Fwd:] Nvidia NICs with duplicate mac addresses Message-ID: <86skseu0hd.fsf@seastrom.com> Forwarded to NANOG in the interests of wider awareness... having been there and torn out my already scarce hair, duplicate MAC addresses can really mess up your day... --- Just when you thought this couldn't happen any more... Copying from a different email list... mac address 04:4b:80:80:80:03, was showing up in multiple places across the network. I googled the mac address and discovered that other people are having the same issue with this mac address. Below are some links describing the problem: http://forums.nvidia.com/index.php?showtopic=22148 http://www.nvnews.net/vbulletin/archive/index.php/t-73469.html I just wanted everyone to know about this problem in case you run across similar slow "connectivity" issues. I believe the network card is made by NVIDIA. From jra at baylink.com Fri Sep 5 09:36:24 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Fri, 5 Sep 2008 10:36:24 -0400 Subject: [Fwd:] Nvidia NICs with duplicate mac addresses In-Reply-To: <86skseu0hd.fsf@seastrom.com> References: <86skseu0hd.fsf@seastrom.com> Message-ID: <20080905143624.GF17757@cgi.jachomes.com> On Fri, Sep 05, 2008 at 10:32:46AM -0400, Robert E. Seastrom wrote: > mac address 04:4b:80:80:80:03, was showing up in multiple places > across the network. I googled the mac address and discovered that > other people are having the same issue with this mac address. Below > are some links describing the problem: > > http://forums.nvidia.com/index.php?showtopic=22148 > http://www.nvnews.net/vbulletin/archive/index.php/t-73469.html > > I just wanted everyone to know about this problem in case you run > across similar slow "connectivity" issues. I believe the network card > is made by NVIDIA. FWIW, IEEE's OUI lookup page says that's not assigned to *anyone*. http://standards.ieee.org/regauth/oui/index.shtml 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 mike at mtcc.com Fri Sep 5 09:46:00 2008 From: mike at mtcc.com (Michael Thomas) Date: Fri, 05 Sep 2008 07:46:00 -0700 Subject: SMTP rate-limits [Was: Re: ingress SMTP] In-Reply-To: <20080905.013610.2431.1@webmail10.vgs.untd.com> References: <20080905.013610.2431.1@webmail10.vgs.untd.com> Message-ID: <48C14628.2050601@mtcc.com> Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > - -- Simon Waters wrote: > > >> If the ISP blocks port 25, then the ISP is taking responsibility for >> > delivering all email sent by a user, and they have to start applying rate > limits. Otherwise if they send all email from their users, all they've done > is take the spam, and mix it in with the legitimate email, making spam > filtering harder. > > > Okay, I can understand why an ISP might want to apply SMTP > rate-limits, but to clarify, I'm assuming you meant that ISPs > (if they do block tcp/25 outbound to anything other than their > own MTAs) need to watch for excessive SMTP utilization, which might > indicate a spammer-client (?). > > ...as opposed to arbitrary SMTP rate-limits. > > Yes? > > I thought that these bot nets were so massive that it is pretty easy for them to fly under the radar for quotas, rate limiting, etc. Not that all bot nets are created equal, and there aren't local hot spots for whatever reason, but putting on the brakes in a way that users wouldn't feel pain is simply not going to make any appreciable difference in the overall mal-rate. No? Mike From scott.berkman at reignmaker.net Fri Sep 5 09:53:28 2008 From: scott.berkman at reignmaker.net (Scott Berkman) Date: Fri, 5 Sep 2008 10:53:28 -0400 (EDT) Subject: [Fwd:] Nvidia NICs with duplicate mac addresses In-Reply-To: <86skseu0hd.fsf@seastrom.com> References: <86skseu0hd.fsf@seastrom.com> Message-ID: <001f01c90f67$46e4d5e0$d4ae81a0$@berkman@reignmaker.net> This reminds me of a story I was told a while back that there was a batch of 3com NIC's that all went out with the same MAC from the factory. I never found out if that was a rumor/urban legend or the truth. Anyone know firsthand or have an article about that? -Scott -----Original Message----- From: Robert E. Seastrom [mailto:rs at seastrom.com] Sent: Friday, September 05, 2008 10:33 AM To: nanog at nanog.org Subject: [Fwd:] Nvidia NICs with duplicate mac addresses Forwarded to NANOG in the interests of wider awareness... having been there and torn out my already scarce hair, duplicate MAC addresses can really mess up your day... --- Just when you thought this couldn't happen any more... Copying from a different email list... mac address 04:4b:80:80:80:03, was showing up in multiple places across the network. I googled the mac address and discovered that other people are having the same issue with this mac address. Below are some links describing the problem: http://forums.nvidia.com/index.php?showtopic=22148 http://www.nvnews.net/vbulletin/archive/index.php/t-73469.html I just wanted everyone to know about this problem in case you run across similar slow "connectivity" issues. I believe the network card is made by NVIDIA. From robert at ufl.edu Fri Sep 5 10:01:53 2008 From: robert at ufl.edu (Robert D. Scott) Date: Fri, 5 Sep 2008 11:01:53 -0400 Subject: [Fwd:] Nvidia NICs with duplicate mac addresses In-Reply-To: <86skseu0hd.fsf@seastrom.com> References: <86skseu0hd.fsf@seastrom.com> Message-ID: <020801c90f68$5556b110$00041330$@edu> Does this MAC present itself all the time, or just during boot? Marvel makes a NIC prevalent in some Dell systems, that presents MAC 0c00.0000.0000 during its startup process. If you run port security, and several people boot their computer within the cam table expiration period, port security will disable the port. You can work around it but it is time consuming in large networks where port security are enabled. 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: Robert E. Seastrom [mailto:rs at seastrom.com] Sent: Friday, September 05, 2008 10:33 AM To: nanog at nanog.org Subject: [Fwd:] Nvidia NICs with duplicate mac addresses Forwarded to NANOG in the interests of wider awareness... having been there and torn out my already scarce hair, duplicate MAC addresses can really mess up your day... --- Just when you thought this couldn't happen any more... Copying from a different email list... mac address 04:4b:80:80:80:03, was showing up in multiple places across the network. I googled the mac address and discovered that other people are having the same issue with this mac address. Below are some links describing the problem: http://forums.nvidia.com/index.php?showtopic=22148 http://www.nvnews.net/vbulletin/archive/index.php/t-73469.html I just wanted everyone to know about this problem in case you run across similar slow "connectivity" issues. I believe the network card is made by NVIDIA. From oberman at es.net Fri Sep 5 10:02:27 2008 From: oberman at es.net (Kevin Oberman) Date: Fri, 05 Sep 2008 08:02:27 -0700 Subject: [Fwd:] Nvidia NICs with duplicate mac addresses In-Reply-To: Your message of "Fri, 05 Sep 2008 10:36:24 EDT." <20080905143624.GF17757@cgi.jachomes.com> Message-ID: <20080905150227.0E2924501A@ptavv.es.net> > Date: Fri, 5 Sep 2008 10:36:24 -0400 > From: "Jay R. Ashworth" > > On Fri, Sep 05, 2008 at 10:32:46AM -0400, Robert E. Seastrom wrote: > > mac address 04:4b:80:80:80:03, was showing up in multiple places > > across the network. I googled the mac address and discovered that > > other people are having the same issue with this mac address. Below > > are some links describing the problem: > > > > http://forums.nvidia.com/index.php?showtopic=22148 > > http://www.nvnews.net/vbulletin/archive/index.php/t-73469.html > > > > I just wanted everyone to know about this problem in case you run > > across similar slow "connectivity" issues. I believe the network card > > is made by NVIDIA. > > FWIW, IEEE's OUI lookup page says that's not assigned to *anyone*. > > http://standards.ieee.org/regauth/oui/index.shtml No, the IEEE page does not say anything. For many years IEEE considered OUIs to be confidential by default. IEEE would list the OUI only if a box was checked on the application for the OUI. At some point the default was changes to make the OUIs public, but existing "private" entries remain private. That said, it turns out the nVidia's OUI is 00:04:4B. So it looks like the addressing was completely hosed and the MAC was shifted over 1 byte. What mess! This used to happen in the early days of Ethernet, but I have not seen it in some time. -- 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 Fri Sep 5 10:05:53 2008 From: oberman at es.net (Kevin Oberman) Date: Fri, 05 Sep 2008 08:05:53 -0700 Subject: [Fwd:] Nvidia NICs with duplicate mac addresses In-Reply-To: Your message of "Fri, 05 Sep 2008 10:53:28 EDT." <001f01c90f67$46e4d5e0$d4ae81a0$@berkman@reignmaker.net> Message-ID: <20080905150553.8E9B44501A@ptavv.es.net> > From: "Scott Berkman" > Date: Fri, 5 Sep 2008 10:53:28 -0400 (EDT) > > This reminds me of a story I was told a while back that there was a batch > of 3com NIC's that all went out with the same MAC from the factory. I > never found out if that was a rumor/urban legend or the truth. Anyone > know firsthand or have an article about that? > > -Scott > > -----Original Message----- > From: Robert E. Seastrom [mailto:rs at seastrom.com] > Sent: Friday, September 05, 2008 10:33 AM > To: nanog at nanog.org > Subject: [Fwd:] Nvidia NICs with duplicate mac addresses > > > Forwarded to NANOG in the interests of wider awareness... having been > there and torn out my already scarce hair, duplicate MAC addresses can > really mess up your day... > > --- > > Just when you thought this couldn't happen any more... > > Copying from a different email list... > > mac address 04:4b:80:80:80:03, was showing up in multiple places > across the network. I googled the mac address and discovered that > other people are having the same issue with this mac address. Below > are some links describing the problem: > > http://forums.nvidia.com/index.php?showtopic=22148 > http://www.nvnews.net/vbulletin/archive/index.php/t-73469.html > > > I just wanted everyone to know about this problem in case you run > across similar slow "connectivity" issues. I believe the network card > is made by NVIDIA. I can attest that it happened. We had several of them when I was at LLNL back in the early '80s. It was amazingly hard to convince the 3Com folks that the cards were not usable. (This is not the only case of this, either, but was probably the biggest in terms of number of cards as 3Com made a very large percentage of all cards in those days. -- 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 jra at baylink.com Fri Sep 5 10:09:26 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Fri, 5 Sep 2008 11:09:26 -0400 Subject: [Fwd:] Nvidia NICs with duplicate mac addresses In-Reply-To: <20080905150227.0E2924501A@ptavv.es.net> References: <20080905143624.GF17757@cgi.jachomes.com> <20080905150227.0E2924501A@ptavv.es.net> Message-ID: <20080905150926.GI17757@cgi.jachomes.com> On Fri, Sep 05, 2008 at 08:02:27AM -0700, Kevin Oberman wrote: > From: "Jay R. Ashworth" > > FWIW, IEEE's OUI lookup page says that's not assigned to *anyone*. > > > > http://standards.ieee.org/regauth/oui/index.shtml > > No, the IEEE page does not say anything. For many years IEEE considered > OUIs to be confidential by default. IEEE would list the OUI only if a > box was checked on the application for the OUI. At some point the > default was changes to make the OUIs public, but existing "private" > entries remain private. Ah, then you're correct; I characterised it worng. Thanks for the clarification; I hadn't realised that. 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 etow at yorktel.com Fri Sep 5 10:22:39 2008 From: etow at yorktel.com (Eric Tow) Date: Fri, 5 Sep 2008 11:22:39 -0400 Subject: [Fwd:] Nvidia NICs with duplicate mac addresses References: <20080905150553.8E9B44501A@ptavv.es.net> Message-ID: Back in 1999, I experienced an issue when we ghosted a number of Compaq desktops and the Intel NICs all ended up with the same MAC address. It turned out that the Intel NIC that was used in the later models was different from the earlier models, so changing the driver resolved the issue. Eric Tow York Telecom E-mail: etow at yorktel.com Phone: 732.413.6077 -----Original Message----- From: Kevin Oberman [mailto:oberman at es.net] Sent: Fri 9/5/2008 11:05 AM To: Scott Berkman Cc: 'Robert E. Seastrom'; nanog at nanog.org Subject: Re: [Fwd:] Nvidia NICs with duplicate mac addresses > From: "Scott Berkman" > Date: Fri, 5 Sep 2008 10:53:28 -0400 (EDT) > > This reminds me of a story I was told a while back that there was a batch > of 3com NIC's that all went out with the same MAC from the factory. I > never found out if that was a rumor/urban legend or the truth. Anyone > know firsthand or have an article about that? > > -Scott > > -----Original Message----- > From: Robert E. Seastrom [mailto:rs at seastrom.com] > Sent: Friday, September 05, 2008 10:33 AM > To: nanog at nanog.org > Subject: [Fwd:] Nvidia NICs with duplicate mac addresses > > > Forwarded to NANOG in the interests of wider awareness... having been > there and torn out my already scarce hair, duplicate MAC addresses can > really mess up your day... > > --- > > Just when you thought this couldn't happen any more... > > Copying from a different email list... > > mac address 04:4b:80:80:80:03, was showing up in multiple places > across the network. I googled the mac address and discovered that > other people are having the same issue with this mac address. Below > are some links describing the problem: > > http://forums.nvidia.com/index.php?showtopic=22148 > http://www.nvnews.net/vbulletin/archive/index.php/t-73469.html > > > I just wanted everyone to know about this problem in case you run > across similar slow "connectivity" issues. I believe the network card > is made by NVIDIA. I can attest that it happened. We had several of them when I was at LLNL back in the early '80s. It was amazingly hard to convince the 3Com folks that the cards were not usable. (This is not the only case of this, either, but was probably the biggest in terms of number of cards as 3Com made a very large percentage of all cards in those days. -- 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 dot at dotat.at Fri Sep 5 10:41:30 2008 From: dot at dotat.at (Tony Finch) Date: Fri, 5 Sep 2008 16:41:30 +0100 Subject: SMTP rate-limits [Was: Re: ingress SMTP] In-Reply-To: <48C14628.2050601@mtcc.com> References: <20080905.013610.2431.1@webmail10.vgs.untd.com> <48C14628.2050601@mtcc.com> Message-ID: On Fri, 5 Sep 2008, Michael Thomas wrote: > > I thought that these bot nets were so massive that it is pretty > easy for them to fly under the radar for quotas, rate limiting, etc. > Not that all bot nets are created equal, and there aren't local hot > spots for whatever reason, but putting on the brakes in a way that > users wouldn't feel pain is simply not going to make any appreciable > difference in the overall mal-rate. Right. In practice the rate of delivery failures is a more useful indication of spam than the overall email rate. Tony. -- f.anthony.n.finch http://dotat.at/ IRISH SEA: NORTHEASTERLY BACKING NORTHERLY 6 TO GALE 8, BUT CYCLONIC 5 IN SOUTH AT FIRST. MODERATE BECOMING ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From pauldotwall at gmail.com Fri Sep 5 10:46:29 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Fri, 5 Sep 2008 11:46:29 -0400 Subject: BCP38 dismissal In-Reply-To: <20080904181256.GA20349@force10networks.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> <620fd17c0809041014n26cdcebo784c6de2f932e149@mail.gmail.com> <20080904181256.GA20349@force10networks.com> Message-ID: <620fd17c0809050846g27069a97qdaf3e756627272d8@mail.gmail.com> On Thu, Sep 4, 2008 at 2:12 PM, Greg Hankins wrote: > Hey Paul, would you be able to demonstrate this problem? I'd like to see > it so that we can investigate and fix it. > > You are correct that the first generation of E-Series hardware (EtherScale) > had little control plane protection. > > The current E-Series hardware (TeraScale) has a completely different > architecture that rate limits, queues and filters all packets destined to > the control plane. In my current job, I don't have access to this kind of iron. The afforementioned Linksys solution provides more than enough capacity. If you could provide me login/enable access to a current E-series box with no firewalls sitting in front, I can most likely replicate. (Off-list, in the interest of keeping things on-topic, with a follow-up summary sent on-...) Drive Slow, Paul Wall From bmanning at vacation.karoshi.com Fri Sep 5 10:54:41 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 5 Sep 2008 15:54:41 +0000 Subject: [Fwd:] Nvidia NICs with duplicate mac addresses In-Reply-To: <001f01c90f67$46e4d5e0$d4ae81a0$@berkman@reignmaker.net> References: <86skseu0hd.fsf@seastrom.com> <001f01c90f67$46e4d5e0$d4ae81a0$@berkman@reignmaker.net> Message-ID: <20080905155441.GA13982@vacation.karoshi.com.> it was real. (I still ahve some 3c503's with the problem :) this is one reason why it is so important to be able to override the MAC. --bill On Fri, Sep 05, 2008 at 10:53:28AM -0400, Scott Berkman wrote: > This reminds me of a story I was told a while back that there was a batch > of 3com NIC's that all went out with the same MAC from the factory. I > never found out if that was a rumor/urban legend or the truth. Anyone > know firsthand or have an article about that? > > -Scott > > -----Original Message----- > From: Robert E. Seastrom [mailto:rs at seastrom.com] > Sent: Friday, September 05, 2008 10:33 AM > To: nanog at nanog.org > Subject: [Fwd:] Nvidia NICs with duplicate mac addresses > > > Forwarded to NANOG in the interests of wider awareness... having been > there and torn out my already scarce hair, duplicate MAC addresses can > really mess up your day... > > --- > > Just when you thought this couldn't happen any more... > > Copying from a different email list... > > mac address 04:4b:80:80:80:03, was showing up in multiple places > across the network. I googled the mac address and discovered that > other people are having the same issue with this mac address. Below > are some links describing the problem: > > http://forums.nvidia.com/index.php?showtopic=22148 > http://www.nvnews.net/vbulletin/archive/index.php/t-73469.html > > > I just wanted everyone to know about this problem in case you run > across similar slow "connectivity" issues. I believe the network card > is made by NVIDIA. > > From nanog at shankland.org Fri Sep 5 11:04:27 2008 From: nanog at shankland.org (Jim Shankland) Date: Fri, 05 Sep 2008 09:04:27 -0700 Subject: [Fwd:] Nvidia NICs with duplicate mac addresses In-Reply-To: <20080905155441.GA13982@vacation.karoshi.com.> References: <86skseu0hd.fsf@seastrom.com> <001f01c90f67$46e4d5e0$d4ae81a0$@berkman@reignmaker.net> <20080905155441.GA13982@vacation.karoshi.com.> Message-ID: <48C1588B.4000608@shankland.org> The Nvidia NIC on the Asus motherboard on my desktop computer spontaneously changed its MAC maybe a year ago from 00:13:d4:fe:04:ee to 00:0b:e0:f0:00:ed. It can still be overridden in software, but the default MAC address -- the one stored in "ROM" -- simply made a one-time, spontaneous, permanent change. Nvidia NICs ... as my mother said, if you can't say anything nice, don't say anything at all. So the rest is silence. Jim Shankland From David_Hankins at isc.org Fri Sep 5 11:36:06 2008 From: David_Hankins at isc.org (David W. Hankins) Date: Fri, 5 Sep 2008 09:36:06 -0700 Subject: [Fwd:] Nvidia NICs with duplicate mac addresses In-Reply-To: <86skseu0hd.fsf@seastrom.com> References: <86skseu0hd.fsf@seastrom.com> Message-ID: <20080905163606.GE5333@isc.org> On Fri, Sep 05, 2008 at 10:32:46AM -0400, Robert E. Seastrom wrote: > Forwarded to NANOG in the interests of wider awareness... having been > there and torn out my already scarce hair, duplicate MAC addresses can > really mess up your day... Out of curiosity, does this happen often enough we might want to consider an automated means to negotiate out of the problem state (e.g. detect collisions and negotiate MAC address by DHCP)? It would take years to deploy but might save thousands of hairs. -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ -- 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: 194 bytes Desc: not available URL: From alec.berry at restontech.com Fri Sep 5 11:48:48 2008 From: alec.berry at restontech.com (Alec Berry) Date: Fri, 05 Sep 2008 12:48:48 -0400 Subject: [Fwd:] Nvidia NICs with duplicate mac addresses In-Reply-To: <86skseu0hd.fsf@seastrom.com> References: <86skseu0hd.fsf@seastrom.com> Message-ID: <48C162F0.7000406@restontech.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert E. Seastrom wrote: > Just when you thought this couldn't happen any more... > > Copying from a different email list... > > mac address 04:4b:80:80:80:03, was showing up in multiple places > across the network. That's why I stick to ARCNET :) ... alec - -- `____________ / Alec Berry \______________________________ | Senior Partner and Director of Technology \ | PGP/GPG key 0xE8E9030F | | http://alec.restontech.com/#PGP | |-------------------------------------------| | RestonTech, Ltd. | | http://www.restontech.com/ | | Phone: (703) 234-2914 | \___________________________________________/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIwWLuREO1P+jpAw8RAm32AKCL5p2yYfeVcUR7BJ16HfS6Rs3XjwCePlc2 wh3Vf0a6MgCe48BICDJufu0= =+YLd -----END PGP SIGNATURE----- From Jon.Kibler at aset.com Fri Sep 5 11:56:20 2008 From: Jon.Kibler at aset.com (Jon Kibler) Date: Fri, 05 Sep 2008 12:56:20 -0400 Subject: [Fwd:] Nvidia NICs with duplicate mac addresses In-Reply-To: <020801c90f68$5556b110$00041330$@edu> References: <86skseu0hd.fsf@seastrom.com> <020801c90f68$5556b110$00041330$@edu> Message-ID: <48C164B4.6030902@aset.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert D. Scott wrote: > Does this MAC present itself all the time, or just during boot? > > Marvel makes a NIC prevalent in some Dell systems, that presents MAC > 0c00.0000.0000 during its startup process. If you run port security, and > several people boot their computer within the cam table expiration period, > port security will disable the port. You can work around it but it is time > consuming in large networks where port security are enabled. > I know that this doesn't apply here, but a year or so ago I had a client that had issues with port security continually dropping an end user's PC. The problem was the MAC address kept changing from Realtek to Cisco. Sometimes the same NIC would present both MACs at the same time. It turned out the box was apparently infected with something. Never could find anything specific (even when booting the Windows box from Knoppix and scanning for unusual files) except for some large ADS files that where apparently encrypted. A clean wipe and complete rebuild of the box fixed the problem. Jon - -- 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 iEYEARECAAYFAkjBZLQACgkQUVxQRc85QlMUpwCfQXrML+jZ8Lkwh3z2QuvldWh6 6+YAn3eqq2GBv7qof+urEGtibAKQf/6m =un9B -----END PGP SIGNATURE----- ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email. From robert at ufl.edu Fri Sep 5 12:04:37 2008 From: robert at ufl.edu (Robert D. Scott) Date: Fri, 5 Sep 2008 13:04:37 -0400 Subject: [Fwd:] Nvidia NICs with duplicate mac addresses In-Reply-To: <48C164B4.6030902@aset.com> References: <86skseu0hd.fsf@seastrom.com> <020801c90f68$5556b110$00041330$@edu> <48C164B4.6030902@aset.com> Message-ID: <002701c90f79$7a55e9c0$6f01bd40$@edu> The Marvel NIC presents the MAC as what we believe to be part of dot1x negotiation. These were new Dells out of the box, not yet infected. If we disable dot1x on the NIC the problem goes away. http://www.cisco.com/en/US/docs/switches/lan/catalyst3750e_3560e/software/re lease/12.2_44_se/release/notes/OL14629.html#wp885689 Cisco's Recommendation: Replace the NIC 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: Jon Kibler [mailto:Jon.Kibler at aset.com] Sent: Friday, September 05, 2008 12:56 PM To: nanog at nanog.org Cc: 'Robert E. Seastrom' Subject: Re: [Fwd:] Nvidia NICs with duplicate mac addresses -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert D. Scott wrote: > Does this MAC present itself all the time, or just during boot? > > Marvel makes a NIC prevalent in some Dell systems, that presents MAC > 0c00.0000.0000 during its startup process. If you run port security, and > several people boot their computer within the cam table expiration period, > port security will disable the port. You can work around it but it is time > consuming in large networks where port security are enabled. > I know that this doesn't apply here, but a year or so ago I had a client that had issues with port security continually dropping an end user's PC. The problem was the MAC address kept changing from Realtek to Cisco. Sometimes the same NIC would present both MACs at the same time. It turned out the box was apparently infected with something. Never could find anything specific (even when booting the Windows box from Knoppix and scanning for unusual files) except for some large ADS files that where apparently encrypted. A clean wipe and complete rebuild of the box fixed the problem. Jon - -- 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 iEYEARECAAYFAkjBZLQACgkQUVxQRc85QlMUpwCfQXrML+jZ8Lkwh3z2QuvldWh6 6+YAn3eqq2GBv7qof+urEGtibAKQf/6m =un9B -----END PGP SIGNATURE----- ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email. From rs at seastrom.com Fri Sep 5 12:19:44 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Fri, 05 Sep 2008 13:19:44 -0400 Subject: [Fwd:] Nvidia NICs with duplicate mac addresses In-Reply-To: <20080905163606.GE5333@isc.org> (David W. Hankins's message of "Fri, 5 Sep 2008 09:36:06 -0700") References: <86skseu0hd.fsf@seastrom.com> <20080905163606.GE5333@isc.org> Message-ID: <86ljy6ldcf.fsf@seastrom.com> "David W. Hankins" writes: > On Fri, Sep 05, 2008 at 10:32:46AM -0400, Robert E. Seastrom wrote: >> Forwarded to NANOG in the interests of wider awareness... having been >> there and torn out my already scarce hair, duplicate MAC addresses can >> really mess up your day... > > Out of curiosity, does this happen often enough we might want to > consider an automated means to negotiate out of the problem state > (e.g. detect collisions and negotiate MAC address by DHCP)? > > It would take years to deploy but might save thousands of hairs. The same DHCP server (ip helper-address blah) serves my office, my home, and the colo. Can you give me an idea of a good heuristic for telling the difference between moving my laptop around and finding MAC address collisions? Or are you suggesting that you hand out a MAC address along with an IP address when the client DHCPs and the client then changes it? -r From jkinz at kinz.org Fri Sep 5 12:38:32 2008 From: jkinz at kinz.org (Jeff Kinz) Date: Fri, 5 Sep 2008 13:38:32 -0400 Subject: ingress SMTP In-Reply-To: References: <20080904185730.GC14670@redline.kinz.org> <12462.119.15.0.26.1220571234.squirrel@webmail.blakjak.net> <200809050921.17516.simonw@zynet.net> Message-ID: <20080905173832.GA11199@redline.kinz.org> On Fri, Sep 05, 2008 at 10:35:15AM +0200, Mikael Abrahamsson wrote: > On Fri, 5 Sep 2008, Simon Waters wrote: > > >If the ISP blocks port 25, then the ISP is taking responsibility for > >delivering all email sent by a user, and they have to start applying rate > >limits. > > MUAs should stop sending email via 25 and use 587 or equivalent instead. > There is little actual reason why someone should be able to send TCP/25 > SMTP email from a residential connection when most software support > authenticated TCP/587 submits. Just FYI- the ISP has the same 220 email address limit even when I send thru port 587, authenticated. (its comcast) > > We don't allow most of our residential customer base to speak SMTP TCP/25 > to anywhere at all (and we have millions of them). Wish more ISPs would do > the same. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se -- From cscora at apnic.net Fri Sep 5 13:13:19 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 6 Sep 2008 04:13:19 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200809051813.m85IDJ1B008093@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 06 Sep, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 267551 Prefixes after maximum aggregation: 129558 Deaggregation factor: 2.07 Unique aggregates announced to Internet: 130250 Total ASes present in the Internet Routing Table: 29147 Prefixes per ASN: 9.18 Origin-only ASes present in the Internet Routing Table: 25360 Origin ASes announcing only one prefix: 12310 Transit ASes present in the Internet Routing Table: 3787 Transit-only ASes present in the Internet Routing Table: 83 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 26 Max AS path prepend of ASN ( 3816) 15 Prefixes from unregistered ASNs in the Routing Table: 568 Unregistered ASNs in the Routing Table: 211 Number of 32-bit ASNs allocated by the RIRs: 59 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: 761 Number of addresses announced to Internet: 1897392032 Equivalent to 113 /8s, 23 /16s and 231 /24s Percentage of available address space announced: 51.2 Percentage of allocated address space announced: 62.2 Percentage of available address space allocated: 82.3 Percentage of address space in use by end-sites: 73.4 Total number of prefixes smaller than registry allocations: 131274 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 61606 Total APNIC prefixes after maximum aggregation: 22776 APNIC Deaggregation factor: 2.70 Prefixes being announced from the APNIC address blocks: 58521 Unique aggregates announced from the APNIC address blocks: 26310 APNIC Region origin ASes present in the Internet Routing Table: 3366 APNIC Prefixes per ASN: 17.39 APNIC Region origin ASes announcing only one prefix: 900 APNIC Region transit ASes present in the Internet Routing Table: 526 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 19 Number of APNIC addresses announced to Internet: 375010592 Equivalent to 22 /8s, 90 /16s and 53 /24s Percentage of available APNIC address space announced: 79.8 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: 122144 Total ARIN prefixes after maximum aggregation: 64686 ARIN Deaggregation factor: 1.89 Prefixes being announced from the ARIN address blocks: 91338 Unique aggregates announced from the ARIN address blocks: 35015 ARIN Region origin ASes present in the Internet Routing Table: 12424 ARIN Prefixes per ASN: 7.35 ARIN Region origin ASes announcing only one prefix: 4790 ARIN Region transit ASes present in the Internet Routing Table: 1186 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 16 Number of ARIN addresses announced to Internet: 360988896 Equivalent to 21 /8s, 132 /16s and 64 /24s Percentage of available ARIN address space announced: 74.2 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: 57792 Total RIPE prefixes after maximum aggregation: 35026 RIPE Deaggregation factor: 1.65 Prefixes being announced from the RIPE address blocks: 52942 Unique aggregates announced from the RIPE address blocks: 35549 RIPE Region origin ASes present in the Internet Routing Table: 11818 RIPE Prefixes per ASN: 4.48 RIPE Region origin ASes announcing only one prefix: 6203 RIPE Region transit ASes present in the Internet Routing Table: 1806 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 26 Number of RIPE addresses announced to Internet: 371067328 Equivalent to 22 /8s, 30 /16s and 9 /24s Percentage of available RIPE address space announced: 85.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: 21370 Total LACNIC prefixes after maximum aggregation: 5344 LACNIC Deaggregation factor: 4.00 Prefixes being announced from the LACNIC address blocks: 19602 Unique aggregates announced from the LACNIC address blocks: 10867 LACNIC Region origin ASes present in the Internet Routing Table: 992 LACNIC Prefixes per ASN: 19.76 LACNIC Region origin ASes announcing only one prefix: 327 LACNIC Region transit ASes present in the Internet Routing Table: 166 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 17 Number of LACNIC addresses announced to Internet: 55077376 Equivalent to 3 /8s, 72 /16s and 106 /24s Percentage of available LACNIC address space announced: 54.7 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: 4072 Total AfriNIC prefixes after maximum aggregation: 1255 AfriNIC Deaggregation factor: 3.24 Prefixes being announced from the AfriNIC address blocks: 4387 Unique aggregates announced from the AfriNIC address blocks: 1967 AfriNIC Region origin ASes present in the Internet Routing Table: 258 AfriNIC Prefixes per ASN: 17.00 AfriNIC Region origin ASes announcing only one prefix: 90 AfriNIC Region transit ASes present in the Internet Routing Table: 55 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 16 Number of AfriNIC addresses announced to Internet: 12672768 Equivalent to 0 /8s, 193 /16s and 95 /24s Percentage of available AfriNIC address space announced: 37.8 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 1715 538 181 Videsh Sanchar Nigam Ltd. Aut 17488 1372 90 102 Hathway IP Over Cable Interne 9583 1147 89 495 Sify Limited 4766 873 6407 357 Korea Telecom (KIX) 4134 841 13651 345 CHINANET-BACKBONE 23577 820 35 695 Korea Telecom (ATM-MPLS) 18101 715 167 29 Reliance Infocom Ltd Internet 4780 714 353 61 Digital United Inc. 9498 677 291 52 BHARTI BT INTERNET LTD. 4808 629 1156 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 4292 3416 337 bellsouth.net, inc. 209 2904 3873 618 Qwest 6298 1973 315 759 Cox Communicatons 1785 1651 710 156 AppliedTheory Corporation 20115 1568 1260 703 Charter Communications 2386 1560 691 899 AT&T Data Communications Serv 4323 1506 1073 375 Time Warner Telecom 7018 1399 5782 975 AT&T WorldNet Services 11492 1211 151 18 Cable One 6478 1140 239 181 AT&T Worldnet Services 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 416 1776 373 TDC Tele Danmark 3301 334 1444 305 TeliaNet Sweden 8452 328 188 11 TEDATA 3215 327 2756 106 France Telecom Transpac 3320 326 7063 274 Deutsche Telekom AG 30890 322 87 176 SC Kappa Invexim SRL 8866 316 77 21 Bulgarian Telecommunication C 5462 296 794 27 Telewest Broadband 8551 287 270 37 Bezeq International 680 275 2047 265 DFN-IP service G-WiN 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 1594 2608 228 UniNet S.A. de C.V. 11830 664 299 9 Instituto Costarricense de El 22047 564 270 14 VTR PUNTO NET S.A. 7303 485 239 67 Telecom Argentina Stet-France 16814 426 27 10 NSS, S.A. 10620 422 103 62 TVCABLE BOGOTA 6471 421 85 48 ENTEL CHILE S.A. 11172 408 118 71 Servicios Alestra S.A de C.V 14117 345 23 9 Telefonica del Sur S.A. 28573 337 441 29 NET Servicos de Comunicao S.A 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 515 65 36 LINKdotNET AS number 20858 402 34 3 EgyNet 3741 265 855 223 The Internet Solution 2018 233 214 138 Tertiary Education Network 6713 143 135 11 Itissalat Al-MAGHRIB 33783 137 10 13 EEPAD TISP TELECOM & INTERNET 5536 120 8 17 Internet Egypt Network 33776 119 6 3 Starcomms Nigeria Limited 5713 118 555 68 Telkom SA Ltd 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 4292 3416 337 bellsouth.net, inc. 209 2904 3873 618 Qwest 6298 1973 315 759 Cox Communicatons 4755 1715 538 181 Videsh Sanchar Nigam Ltd. Aut 1785 1651 710 156 AppliedTheory Corporation 8151 1594 2608 228 UniNet S.A. de C.V. 20115 1568 1260 703 Charter Communications 2386 1560 691 899 AT&T Data Communications Serv 4323 1506 1073 375 Time Warner Telecom 7018 1399 5782 975 AT&T WorldNet Services Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2904 2286 Qwest 4755 1715 1534 Videsh Sanchar Nigam Ltd. Aut 1785 1651 1495 AppliedTheory Corporation 8151 1594 1366 UniNet S.A. de C.V. 17488 1372 1270 Hathway IP Over Cable Interne 6298 1973 1214 Cox Communicatons 11492 1211 1193 Cable One 4323 1506 1131 Time Warner Telecom 18566 1048 1038 Covad Communications 6478 1140 959 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 7018 AT&T WorldNet Servic 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 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.75.160.0/19 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 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio 63.143.71.0/24 701 UUNET Technologies, Inc. 63.143.115.0/24 701 UUNET Technologies, Inc. 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:17 /11:45 /12:146 /13:293 /14:527 /15:1060 /16:10060 /17:4380 /18:7636 /19:16082 /20:18794 /21:18490 /22:23203 /23:24269 /24:139965 /25:772 /26:940 /27:739 /28:89 /29:9 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2851 4292 bellsouth.net, inc. 6298 1948 1973 Cox Communicatons 209 1671 2904 Qwest 2386 1238 1560 AT&T Data Communications Serv 11492 1192 1211 Cable One 17488 1180 1372 Hathway IP Over Cable Interne 1785 1121 1651 AppliedTheory Corporation 4755 1050 1715 Videsh Sanchar Nigam Ltd. Aut 6478 1033 1140 AT&T Worldnet Services 18566 1029 1048 Covad Communications Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:8 8:137 12:2147 13:2 15:22 16:3 17:5 18:13 20:35 24:1087 32:59 38:490 40:92 41:721 43:1 44:2 47:12 52:3 55:3 56:3 57:26 58:526 59:518 60:453 61:961 62:1223 63:2046 64:3210 65:2358 66:3458 67:1230 68:774 69:2297 70:845 71:169 72:2028 73:6 74:1135 75:170 76:274 77:791 78:799 79:318 80:949 81:833 82:573 83:369 84:574 85:972 86:399 87:714 88:337 89:1325 90:20 91:1446 92:254 93:817 94:132 96:63 97:68 98:323 99:7 114:96 115:42 116:1018 117:355 118:237 119:483 120:84 121:587 122:837 123:400 124:853 125:1193 128:356 129:201 130:134 131:410 132:70 133:9 134:178 135:34 136:223 137:93 138:141 139:93 140:508 141:102 142:407 143:289 144:362 145:51 146:371 147:157 148:514 149:206 150:128 151:181 152:145 153:136 154:10 155:284 156:175 157:297 158:163 159:301 160:273 161:139 162:254 163:155 164:516 165:497 166:367 167:331 168:629 169:143 170:431 171:33 172:10 173:33 188:1 189:593 190:2099 192:5791 193:4142 194:3250 195:2579 196:995 198:3735 199:3307 200:5588 201:1525 202:7681 203:8069 204:3935 205:2144 206:2350 207:2738 208:3536 209:3425 210:2602 211:1089 212:1420 213:1621 214:178 215:50 216:4365 217:1212 218:347 219:436 220:1061 221:426 222:315 End of report From David_Hankins at isc.org Fri Sep 5 13:15:04 2008 From: David_Hankins at isc.org (David W. Hankins) Date: Fri, 5 Sep 2008 11:15:04 -0700 Subject: [Fwd:] Nvidia NICs with duplicate mac addresses In-Reply-To: <86ljy6ldcf.fsf@seastrom.com> References: <86skseu0hd.fsf@seastrom.com> <20080905163606.GE5333@isc.org> <86ljy6ldcf.fsf@seastrom.com> Message-ID: <20080905181503.GF5333@isc.org> On Fri, Sep 05, 2008 at 01:19:44PM -0400, Robert E. Seastrom wrote: > The same DHCP server (ip helper-address blah) serves my office, my > home, and the colo. Can you give me an idea of a good heuristic for > telling the difference between moving my laptop around and finding MAC > address collisions? The theoretically conforming client supplies two pieces of information; Its DHCPv4 client-identifier-option (per RFC 4361), which will be different even on systems with identical MAC addresses (unless you are very lucky). The 'chaddr' BOOTP header contents ("its current MAC address"), which is a return-address for unicast replies (before the client has an IP address, ARP doesn't work). The DHCPv4 client-identifier tells us it's a specific interface on your laptop, no matter where it boots. Context from the packet (giaddr (relay-agent address on that network), the interface it was received upon) is used in normal DHCPv* operation (since its dawn) to find a broadcast domain. From there, we find subnets on that domain, and dynamic addresses within that subnet that are appropriate. This is how we locate configuration when your laptop connects to different wires in normal operation. The new trick is to detect two clients with the same MAC address, but with different client identifiers, that are active on the same broadcast domain. It's just a simple database lookup to detect a collision. The solution is to: > Or are you suggesting that you hand out a MAC > address along with an IP address when the client DHCPs and the client > then changes it? Precisely. Negotiate a new address in a broadcast reply. I suppose you could just as easily always allocate a MAC dynamically, but this seems invasive. An alternative solution is to deny the client from receiving a config, signalling an error to the operator, so the first client remains operational. But this can have false positives. It'd take years to deploy tho. Many clients today send no identifier and just use their chaddr contents. Their MAC is their ID, so there is no way to detect collisions. Most others send a client-id that is identical to their chaddr contents, which is approximately useless. You'd also be suffering MAC changes on systems that boot multiple operating systems without releasing their previous lease (because the clients send inconsistent identifiers, and even with DUID-based id's, I think this is not going to change). This is in addition to today, where such clients consume multiple IPv4 addresses. Insult to injury. -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ -- 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: 194 bytes Desc: not available URL: From pauldotwall at gmail.com Fri Sep 5 14:37:26 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Fri, 5 Sep 2008 15:37:26 -0400 Subject: Force10 Gear - Opinions In-Reply-To: <9DEC696A-A850-46DE-BBB9-13E6C8B4CBAE@netconsonance.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <932F4ABF-B1B4-46FF-8155-E799044E3697@netconsonance.com> <620fd17c0809041007i6d494637tf9017377370cac68@mail.gmail.com> <9DEC696A-A850-46DE-BBB9-13E6C8B4CBAE@netconsonance.com> Message-ID: <620fd17c0809051237u2da20972u5ac2015c69101ca3@mail.gmail.com> Jo Rhett wrote: > Note the "not random" comment. People love to use the random feature of ixia/etc but it rarely displays > actual performance in a production network. Once upon a time, vendors released products which relied on CPU-based "flow" setup. Certain vintages of Cisco, Extreme, Foundry, Riverstone, etc come to mind. These could forward at "line rate" under normal conditions. Sufficient randomization on the sources and/or destinations (DDoS, Windows worm, portscans, ...) and they'd die a spectacular death. Nowadays, this is less of a concern, as the higher-end boxes can program a full routing table (and then some) worth of prefixes in CAM. Either way, I think it's a good test metric. I'd be interested in hearing of why you think that's not the case. Back on topic, doing a couple of gigs of traffic at line rate is a walk in the park for any modern product billed as a "layer 3 switch". The differentiator between, say, a Dell and a Cisco, is in the software and profoundly not the forwarding performance. Jo Rhett wrote: >> No, $65000.00 vs $62240.00. > > I have a current spreadsheet here, and trust me your math went wrong > somewhere. A completely full chassis is only a bit more than what you are > quoting (at list) and the chassis itself is practically free. > > But no, I'm not going to redo the math. I'm not a F10 salesperson and I > have much more important things to do right now. I'd be interested in seeing where I went "wrong", in the interest of setting the record straight. The original poster was interested in how Force 10 stacks up against the competition from a feature and price prospective. He deserves some cold science, and I'm trying to help him out. To wit, you said F10 is cheaper than a comparable Cisco 6500 (in a basic gig-e configuration). I demonstrated that's not the case. You responded with ad-hominem attacks, followed by indifference, and later, claims of emotional distress; still you refuse to provide any hard numbers, claiming it's "not your job". Where I come from, people like that are referred to as sore losers. :) Drive Slow, Paul Wall From pauldotwall at gmail.com Fri Sep 5 14:45:52 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Fri, 5 Sep 2008 15:45:52 -0400 Subject: [Fwd:] Nvidia NICs with duplicate mac addresses In-Reply-To: <48C1588B.4000608@shankland.org> References: <86skseu0hd.fsf@seastrom.com> <20080905155441.GA13982@vacation.karoshi.com.> <48C1588B.4000608@shankland.org> Message-ID: <620fd17c0809051245p47962ff0r8866195ecbc1e627@mail.gmail.com> On Fri, Sep 5, 2008 at 12:04 PM, Jim Shankland wrote: > Nvidia NICs ... as my mother said, if you can't say anything nice, > don't say anything at all. So the rest is silence. Hi Jim, My mother wasn't quite so adamant, she just said "don't cuss", so I'll try to keep it clean as I relate my experiences with these "NICs of our affliction". As you're probably aware, Nvidia doesn't really have it together in terms of playing nicely with open source folks. The Linux driver is horribly reverse-engineered and the execution of the implementation is even worse - it couldn't figure out the card's actual MAC address so it assigned a random (and until recently often invalid, with an OUI from bogus space) address. This resulted in some interesting stuff in our switch logs. My recollection is that FreeBSD was no better. We had one batch that refused to pass traffic at 1000/full even when forced. Left me pining for nice reliable stuff like counterfeit Cisco hardware bought from a shady eBay store out of Hong Kong. But I digress. Eventually we voted with our feet; I gave strict instructions to our build guys to stop wasting our time with crummy NICs with no support, and insisted that they pay the small amount of extra money it takes to go with Intel. If you're looking for a funny "prank" to play on your tech staff, speccing a batch of these, sitting back, and watching the fun would get two thumbs up from me... but otherwise steer clear. Drive Slow, Paul Wall From tkapela at gmail.com Fri Sep 5 16:57:35 2008 From: tkapela at gmail.com (Anton Kapela) Date: Fri, 5 Sep 2008 16:57:35 -0500 Subject: Force10 Gear - Opinions In-Reply-To: <620fd17c0809051237u2da20972u5ac2015c69101ca3@mail.gmail.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <932F4ABF-B1B4-46FF-8155-E799044E3697@netconsonance.com> <620fd17c0809041007i6d494637tf9017377370cac68@mail.gmail.com> <9DEC696A-A850-46DE-BBB9-13E6C8B4CBAE@netconsonance.com> <620fd17c0809051237u2da20972u5ac2015c69101ca3@mail.gmail.com> Message-ID: <2e9d8ae50809051457q42c55407gd8745c9ef33a9541@mail.gmail.com> On Fri, Sep 5, 2008 at 2:37 PM, Paul Wall wrote: > Jo Rhett wrote: >> Note the "not random" comment. People love to use the random feature of ixia/etc but it rarely displays >> actual performance in a production network. > > Once upon a time, vendors released products which relied on CPU-based > "flow" setup. Certain vintages of Cisco, Extreme, Foundry, > Riverstone, etc come to mind. These could forward at "line rate" > under normal conditions. Sufficient randomization on the sources Jo, As Paul eludes, the measure of 'worth' today has moved from bits/sec to one of 'operations per second' - where 'operation' could be many different types of work. The 'ideal router' should be able to execute administrative policy, scheduling, queuing, and of course, route lookup and next-hop determination in as close to constant-time as possible without regard for the packet or traffic composition. This means that regardless the makeup or nature of the packet, the device is able to do the same number of lookups with 10, 1000, or 1,000,000 routes in its FIB. Commonly this is done through CAM and TCAM or in RAM using various data structures that exhibit efficient traversal and lookup behaviors. I would invite you to research these independently, as there is a sizable body of work to review (ultimately this work is a class of search/sort problem). Today we find most CAM based systems no longer are interesting insofar as their raw forwarding performance; nearly every feature that can be implemented in hardware will generally exhibit the same scaling and performance behaviors as regular IP forwarding. The same generally holds true for RAM-based systems, though implementations vary by vendor (i.e. juniper IP-I/IP-II vs. MX-series distributed CAM) and can preclude certain combinations of work being performed on the packet during forwarding. Bottom line: it's not bits/sec, it's ops/sec. -Tk From dsinn at dsinn.com Fri Sep 5 17:36:42 2008 From: dsinn at dsinn.com (David Sinn) Date: Fri, 5 Sep 2008 15:36:42 -0700 Subject: an effect of ignoring BCP38 In-Reply-To: <20080905052227.GA8309@vacation.karoshi.com.> References: <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> <3861BD57-759F-4EE5-A274-DBCDE7F7485B@ianai.net> <20080905052227.GA8309@vacation.karoshi.com.> Message-ID: <12211F47-DE02-46BC-833D-24104391838F@dsinn.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I don't think you will get any argument that the vast majority of CS departments teach theory and not as much valid practice when it comes to networking. Though, being formally at the UW, I can tell you that they wouldn't have been able to spoof on the campus or through it's upstream (which we also ran). That being said, I think another area that BCP38 is going to run into problems with is IPv6. Given that host are multi-addressed from day one and nominally follow a default route for returning traffic, they can easily appear to "spoof" perfectly valid traffic (6to4 in, native out for example). While some can be made as exceptions (6to4), some won't be done so easily without some implementation changes. And that's not even touching on the holes in RPF checks on Cisco (no feasible) or Juniper (not quite as feasible as is really feasible) platforms. David On Sep 4, 2008, at 10:22 PM, bmanning at vacation.karoshi.com wrote: > > > seems that some folks in the R&E community, with institutional support > from Cisco, Google, and the US NSF, are exploiting our inability to > take even rudimentary steps toward providing a level of integrity in > routing by teaching students that spoofing IP space is ok. This whole > thing works at all because so few people use/deploy/maintain BCP-38 > compliance. This was an eye-opener for me. > > http://www.caida.org/workshops/wide/0808/slides/measuring_reverse_paths.pdf > > > --bill -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkjBtHoACgkQLa9jIE3ZamPYzQCgu2OdDu8/Uq896ffcJZjSX7X8 6jgAnR7iZFiRAsxN6+qn64ZVYIcNy1hy =E20v -----END PGP SIGNATURE----- From ge at linuxbox.org Sat Sep 6 08:47:53 2008 From: ge at linuxbox.org (Gadi Evron) Date: Sat, 6 Sep 2008 08:47:53 -0500 (CDT) Subject: only WV FIBER now peering with Atrivo / Intercage Message-ID: http://cidr-report.org/cgi-bin/as-report?as=AS27595&v=4&view=2.0#AS27595 Gadi. From kc at caida.org Sat Sep 6 08:49:05 2008 From: kc at caida.org (k claffy) Date: Sat, 6 Sep 2008 06:49:05 -0700 Subject: an effect of ignoring BCP38 In-Reply-To: <20080905052227.GA8309@vacation.karoshi.com.> References: <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> <3861BD57-759F-4EE5-A274-DBCDE7F7485B@ianai.net> <20080905052227.GA8309@vacation.karoshi.com.> Message-ID: <20080906134905.GA75970@rommie.caida.org> do that many networks really allow spoofing? i used to think so, based on hearsay, but rob beverly's http://spoofer.csail.mit.edu/summary.php suggests things are a lot better than they used to be, arbor's last survey echos same. are rob's numbers inconsistent with numbers anyone else believes to be true? i think you unfairly characterize UW's work, but i also think you make questionable inferences regarding the extent of spoofing, which seems more relevant to nanog. k On Fri, Sep 05, 2008 at 05:22:27AM +0000, bmanning at vacation.karoshi.com wrote: seems that some folks in the R&E community, with institutional support from Cisco, Google, and the US NSF, are exploiting our inability to take even rudimentary steps toward providing a level of integrity in routing by teaching students that spoofing IP space is ok. This whole thing works at all because so few people use/deploy/maintain BCP-38 compliance. This was an eye-opener for me. http://www.caida.org/workshops/wide/0808/slides/measuring_reverse_paths.pdf --bill From ge at linuxbox.org Sat Sep 6 11:31:40 2008 From: ge at linuxbox.org (Gadi Evron) Date: Sat, 6 Sep 2008 11:31:40 -0500 (CDT) Subject: only WV FIBER now peering with Atrivo / Intercage In-Reply-To: References: Message-ID: Or is it? On Sat, 6 Sep 2008, Gadi Evron wrote: > http://cidr-report.org/cgi-bin/as-report?as=AS27595&v=4&view=2.0#AS27595 > > Gadi. > From tkapela at gmail.com Sat Sep 6 12:20:34 2008 From: tkapela at gmail.com (Anton Kapela) Date: Sat, 6 Sep 2008 12:20:34 -0500 Subject: Cisco uRPF failures In-Reply-To: <5188BB8F-8EFC-4FCA-BA9F-E36E6C3CEB81@netconsonance.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <00c401c9072b$f46a38c0$dd3eaa40$@com> <007401c90e25$6eaf2280$4c0d6780$@com> <6bb5f5b10809031906m67c18854nb4fe7260ad3e153@mail.gmail.com> <5188BB8F-8EFC-4FCA-BA9F-E36E6C3CEB81@netconsonance.com> Message-ID: <2e9d8ae50809061020x24bdfbf0x3ddcfe3ed8518df2@mail.gmail.com> On Thu, Sep 4, 2008 at 11:35 AM, Jo Rhett wrote: > That's the surprising thing -- no scenario. Very basic configuration. > Enabling uRPF and then hitting it with a few gig of non-routable packets > consistently caused the sup module to stop talking on the console, and What do you mean by 'non routable?' What was the src/dst makeup of the test traffic? > We also discovered problems related to uRPF and load balanced links, but > those were difficult to reproduce in the lab and we couldn't affect their > peering, so we had to disable uRPF and ignore so I don't have much details. What version of code? Also, port-channel/lag or ECMP? > quickly, but that turns out not to be the case. To this day I've never I've never seen the issues you speak of, so it could be code/platform/config specific. Also, what sup were you testing? > found a network operator using uRPF on Cisco gear. > (note: network operator. it's probably fine for several-hundred-meg > enterprise sites) Forgive me, but what does bits/sec have to do with anything? -Tk From tkapela at gmail.com Sat Sep 6 12:23:05 2008 From: tkapela at gmail.com (Anton Kapela) Date: Sat, 6 Sep 2008 12:23:05 -0500 Subject: only WV FIBER now peering with Atrivo / Intercage In-Reply-To: References: Message-ID: <2e9d8ae50809061023r7d962b82td50c050afdeac4c0@mail.gmail.com> On Sat, Sep 6, 2008 at 11:31 AM, Gadi Evron wrote: > Or is it? Looks to not be, so I call BS on your subject line.. however, I do see: * 64.28.176.0/20 71.13.116.101 100 0 20115 19151 26769 27595 i *> 204.11.128.105 100 0 33125 174 3549 27595 i * 67.210.0.0/21 71.13.116.101 100 0 20115 19151 26769 27595 i *> 204.11.128.105 100 0 33125 174 3549 27595 i * 67.210.8.0/22 71.13.116.101 100 0 20115 19151 26769 27595 i 20115 sees 27595 through wv (which peers with bandcon), so it would seem wv shut the edge edge (renesys data also agrees). It's interesting the gx edge is still active. -Tk From pauldotwall at gmail.com Sat Sep 6 12:27:46 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Sat, 6 Sep 2008 13:27:46 -0400 Subject: only WV FIBER now peering with Atrivo / Intercage In-Reply-To: References: Message-ID: <620fd17c0809061027t61094de9j5df248c313c6638b@mail.gmail.com> Gadi, A quick look at route-views will confirm that Atrivo is multi-homed. And WV Fiber is a transit provider to them, not a peer. As NANOG community members in good standing, I'm sure WV, nLayer, etc would take the appropriate action if you were to contact their respective abuse departments, *privately*, with evidence of active abuse on Atrivo's part. Drive Slow, Paul Wall On Sat, Sep 6, 2008 at 9:47 AM, Gadi Evron wrote: > http://cidr-report.org/cgi-bin/as-report?as=AS27595&v=4&view=2.0#AS27595 > > Gadi. > > From christopher.morrow at gmail.com Sat Sep 6 14:13:06 2008 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Sat, 6 Sep 2008 15:13:06 -0400 Subject: Cisco uRPF failures In-Reply-To: <2e9d8ae50809061020x24bdfbf0x3ddcfe3ed8518df2@mail.gmail.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <00c401c9072b$f46a38c0$dd3eaa40$@com> <007401c90e25$6eaf2280$4c0d6780$@com> <6bb5f5b10809031906m67c18854nb4fe7260ad3e153@mail.gmail.com> <5188BB8F-8EFC-4FCA-BA9F-E36E6C3CEB81@netconsonance.com> <2e9d8ae50809061020x24bdfbf0x3ddcfe3ed8518df2@mail.gmail.com> Message-ID: <75cb24520809061213y4ce9118br378d0cafc2618aaf@mail.gmail.com> On 9/6/08, Anton Kapela wrote: > On Thu, Sep 4, 2008 at 11:35 AM, Jo Rhett wrote: > > > found a network operator using uRPF on Cisco gear. > > (note: network operator. it's probably fine for several-hundred-meg > > enterprise sites) > > > Forgive me, but what does bits/sec have to do with anything? > it's possible that on some platforms the uRPF check happens on the main processor, or on a linecard processor. So, bps rates (proxied for by pps rates) matter greatly, on those platforms. -Chris From ge at linuxbox.org Sat Sep 6 16:34:46 2008 From: ge at linuxbox.org (Gadi Evron) Date: Sat, 6 Sep 2008 16:34:46 -0500 (CDT) Subject: only WV FIBER now peering with Atrivo / Intercage In-Reply-To: <2e9d8ae50809061023r7d962b82td50c050afdeac4c0@mail.gmail.com> References: <2e9d8ae50809061023r7d962b82td50c050afdeac4c0@mail.gmail.com> Message-ID: On Sat, 6 Sep 2008, Anton Kapela wrote: > On Sat, Sep 6, 2008 at 11:31 AM, Gadi Evron wrote: >> Or is it? > > Looks to not be, so I call BS on your subject line.. > Thanks Anton! I appreciae you looking into it. > however, I do see: > > * 64.28.176.0/20 71.13.116.101 100 0 20115 > 19151 26769 27595 i > *> 204.11.128.105 100 0 33125 > 174 3549 27595 i > * 67.210.0.0/21 71.13.116.101 100 0 20115 > 19151 26769 27595 i > *> 204.11.128.105 100 0 33125 > 174 3549 27595 i > * 67.210.8.0/22 71.13.116.101 100 0 20115 > 19151 26769 27595 i > > 20115 sees 27595 through wv (which peers with bandcon), so it would > seem wv shut the edge edge (renesys data also agrees). > > It's interesting the gx edge is still active. > > -Tk > From swm at emanon.com Sat Sep 6 18:25:08 2008 From: swm at emanon.com (Scott Morris) Date: Sat, 6 Sep 2008 19:25:08 -0400 Subject: BGP Clueful from Windstream/Alltel? Message-ID: <11d201c91077$cd6a7af0$800610ac@scott66ed7b03d> Is there anyone hanging around here who happens to either be or can get me in touch with a BGP-clueful person at Windstream/Alltel (AS7029)??? Unicast would be great, I hate to tie up the list with this, but the standard prescribed methods haven't worked in 72 hours now... Thanks in advance! Scott Morris swm at emanon.com From patrick at ianai.net Sat Sep 6 18:33:16 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 6 Sep 2008 19:33:16 -0400 Subject: only WV FIBER now peering with Atrivo / Intercage In-Reply-To: <620fd17c0809061027t61094de9j5df248c313c6638b@mail.gmail.com> References: <620fd17c0809061027t61094de9j5df248c313c6638b@mail.gmail.com> Message-ID: <769EDE41-DD8B-419D-B79D-C644AC5A8E2A@ianai.net> On Sep 6, 2008, at 1:27 PM, Paul Wall wrote: > A quick look at route-views will confirm that Atrivo is multi-homed. > And WV Fiber is a transit provider to them, not a peer. > > As NANOG community members in good standing, I'm sure WV, nLayer, etc > would take the appropriate action if you were to contact their > respective abuse departments, *privately*, with evidence of active > abuse on Atrivo's part. Minor correction to your at least implied statement above: nLayer has no direct connectivity to Atrivo, peering or transit. Personally, I'm fine with anyone providing Atrivo transit being shamed in public, but I understand if others do not want such traffic on the list. Anton's post that GX is still providing them transit is a bit curious, since I was under the impression GX had severed all ties with Atrivo. But the table does not lie, a path of "174 3549 27595" is clearly transit. GX, care to comment? -- TTFN, patrick From tkapela at gmail.com Sat Sep 6 19:30:20 2008 From: tkapela at gmail.com (Anton Kapela) Date: Sat, 6 Sep 2008 19:30:20 -0500 Subject: only WV FIBER now peering with Atrivo / Intercage In-Reply-To: <769EDE41-DD8B-419D-B79D-C644AC5A8E2A@ianai.net> References: <620fd17c0809061027t61094de9j5df248c313c6638b@mail.gmail.com> <769EDE41-DD8B-419D-B79D-C644AC5A8E2A@ianai.net> Message-ID: <2e9d8ae50809061730n6e9a9279nad989b1fe7d00e85@mail.gmail.com> On Sat, Sep 6, 2008 at 6:33 PM, Patrick W. Gilmore wrote: > Anton's post that GX is still providing them transit is a bit curious, since > I was under the impression GX had severed all ties with Atrivo. But the > table does not lie, a path of "174 3549 27595" is clearly transit. GX, care > to comment? After poking for a bit, it's unclear what, if anything, GX is or isn't doing here. I tossed a static /24 towards the upstream sending the AS path with GX in it, and traced towards a host in the that /24 - the traceroute output disagrees with the as path, oddly enough. bgp routes, again: r> 58.65.238.0/24 71.13.116.101 100 0 20115 19151 27595 i r 204.11.128.105 100 0 33125 174 3549 27595 i actual path is cogent, (3), wv, intercage, not cogent, gx, intercage: Tracing the route to 58-65-238-1.myrdns.com (58.65.238.1) 1 204.11.128.105 [AS 33125] 0 msec 0 msec 0 msec 2 gi2-15.ccr02.ord03.atlas.cogentco.com (38.104.102.29) [AS 174] 4 msec 4 msec 8 msec 3 te-9-1.car4.Chicago1.Level3.net (4.68.127.129) [AS 3356] 4 msec 8 msec 4 msec 4 ae-32-56.ebr2.Chicago1.Level3.net (4.68.101.190) [AS 3356] 8 msec 20 msec 16 msec 5 ae-5.ebr2.Chicago2.Level3.net (4.69.140.194) [AS 3356] 8 msec 4 msec 8 msec 6 ae-2.ebr2.Washington1.Level3.net (4.69.132.70) [AS 3356] 40 msec 36 msec 36 msec 7 ae-72-72.csw2.Washington1.Level3.net (4.69.134.150) [AS 3356] 36 msec ae-82-82.csw3.Washington1.Level3.net (4.69.134.154) [AS 3356] 40 msec ae-92-92.csw4.Washington1.Level3.net (4.69.134.158) [AS 3356] 40 msec 8 ae-14-69.car4.Washington1.Level3.net (4.68.17.6) [AS 3356] 28 msec ae-24-79.car4.Washington1.Level3.net (4.68.17.70) [AS 3356] 32 msec ae-34-89.car4.Washington1.Level3.net (4.68.17.134) [AS 3356] 32 msec 9 CWIE-LLC.car4.Washington1.Level3.net (4.79.170.146) [AS 3356] 32 msec 32 msec 28 msec 10 * * * 11 atl-ten3-1-ash-ten3-1.wvfiber.net (66.216.1.157) [AS 19151] [MPLS: Label 120 Exp 0] 216 msec 208 msec 188 msec 12 nsh-ten4-1-atl-ten3-2.wvfiber.net (64.127.130.58) [AS 19151] [MPLS: Label 73 Exp 0] 32 msec 32 msec 32 msec 13 la-ten1-1-nsh-ten4-2.wvfiber.net (66.186.197.109) [AS 19151] [MPLS: Label 113 Exp 0] 80 msec 80 msec 80 msec 14 sjc-ten1-1-la-ten1-2.wvfiber.net (66.186.197.106) [AS 19151] 80 msec 84 msec 80 msec 15 58-65-238-1.myrdns.com (58.65.238.1) 84 msec 132 msec 104 msec question I have for the list is...who's faking the funk? -Tk From frnkblk at iname.com Sat Sep 6 20:02:13 2008 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 6 Sep 2008 20:02:13 -0500 Subject: SMTP rate-limits [Was: Re: ingress SMTP] In-Reply-To: <48C14628.2050601@mtcc.com> References: <20080905.013610.2431.1@webmail10.vgs.untd.com> <48C14628.2050601@mtcc.com> Message-ID: Can anyone comment authoritatively on the percentage of spam that's from a leaky faucet compared to fire hose? The stuff I see in my customer base are all fire hoses at the rate of 2.5, sometimes 5 message connection attempts per second. (I bet an academic could study the rate of spam emissions from a certain IP to identify their upstream bandwidth). Frank -----Original Message----- From: Michael Thomas [mailto:mike at mtcc.com] Sent: Friday, September 05, 2008 9:46 AM To: Paul Ferguson Cc: nanog at nanog.org Subject: Re: SMTP rate-limits [Was: Re: ingress SMTP] I thought that these bot nets were so massive that it is pretty easy for them to fly under the radar for quotas, rate limiting, etc. Not that all bot nets are created equal, and there aren't local hot spots for whatever reason, but putting on the brakes in a way that users wouldn't feel pain is simply not going to make any appreciable difference in the overall mal-rate. No? Mike From christian at broknrobot.com Sat Sep 6 20:32:39 2008 From: christian at broknrobot.com (Christian Koch) Date: Sat, 6 Sep 2008 21:32:39 -0400 Subject: only WV FIBER now peering with Atrivo / Intercage In-Reply-To: <2e9d8ae50809061730n6e9a9279nad989b1fe7d00e85@mail.gmail.com> References: <620fd17c0809061027t61094de9j5df248c313c6638b@mail.gmail.com> <769EDE41-DD8B-419D-B79D-C644AC5A8E2A@ianai.net> <2e9d8ae50809061730n6e9a9279nad989b1fe7d00e85@mail.gmail.com> Message-ID: On Sat, Sep 6, 2008 at 8:30 PM, Anton Kapela wrote: > On Sat, Sep 6, 2008 at 6:33 PM, Patrick W. Gilmore wrote: > >> Anton's post that GX is still providing them transit is a bit curious, since >> I was under the impression GX had severed all ties with Atrivo. But the >> table does not lie, a path of "174 3549 27595" is clearly transit. GX, care >> to comment? > > After poking for a bit, it's unclear what, if anything, GX is or isn't > doing here. > > I tossed a static /24 towards the upstream sending the AS path with GX > in it, and traced towards a host in the that /24 - the traceroute > output disagrees with the as path, oddly enough. > > bgp routes, again: > > r> 58.65.238.0/24 71.13.116.101 100 0 20115 19151 27595 i > r 204.11.128.105 100 0 33125 174 3549 27595 i > > actual path is cogent, (3), wv, intercage, not cogent, gx, intercage: > > Tracing the route to 58-65-238-1.myrdns.com (58.65.238.1) > > 1 204.11.128.105 [AS 33125] 0 msec 0 msec 0 msec > 2 gi2-15.ccr02.ord03.atlas.cogentco.com (38.104.102.29) [AS 174] 4 > msec 4 msec 8 msec > 3 te-9-1.car4.Chicago1.Level3.net (4.68.127.129) [AS 3356] 4 msec 8 > msec 4 msec > 4 ae-32-56.ebr2.Chicago1.Level3.net (4.68.101.190) [AS 3356] 8 msec > 20 msec 16 msec > 5 ae-5.ebr2.Chicago2.Level3.net (4.69.140.194) [AS 3356] 8 msec 4 msec 8 msec > 6 ae-2.ebr2.Washington1.Level3.net (4.69.132.70) [AS 3356] 40 msec > 36 msec 36 msec > 7 ae-72-72.csw2.Washington1.Level3.net (4.69.134.150) [AS 3356] 36 msec > ae-82-82.csw3.Washington1.Level3.net (4.69.134.154) [AS 3356] 40 msec > ae-92-92.csw4.Washington1.Level3.net (4.69.134.158) [AS 3356] 40 msec > 8 ae-14-69.car4.Washington1.Level3.net (4.68.17.6) [AS 3356] 28 msec > ae-24-79.car4.Washington1.Level3.net (4.68.17.70) [AS 3356] 32 msec > ae-34-89.car4.Washington1.Level3.net (4.68.17.134) [AS 3356] 32 msec > 9 CWIE-LLC.car4.Washington1.Level3.net (4.79.170.146) [AS 3356] 32 > msec 32 msec 28 msec > 10 * * * > 11 atl-ten3-1-ash-ten3-1.wvfiber.net (66.216.1.157) [AS 19151] [MPLS: > Label 120 Exp 0] 216 msec 208 msec 188 msec > 12 nsh-ten4-1-atl-ten3-2.wvfiber.net (64.127.130.58) [AS 19151] > [MPLS: Label 73 Exp 0] 32 msec 32 msec 32 msec > 13 la-ten1-1-nsh-ten4-2.wvfiber.net (66.186.197.109) [AS 19151] > [MPLS: Label 113 Exp 0] 80 msec 80 msec 80 msec > 14 sjc-ten1-1-la-ten1-2.wvfiber.net (66.186.197.106) [AS 19151] 80 > msec 84 msec 80 msec > 15 58-65-238-1.myrdns.com (58.65.238.1) 84 msec 132 msec 104 msec > > question I have for the list is...who's faking the funk? second that... from ripe bgplay view, gx is never seen as an adjacency to 27595, just wv and bandcon, with liteup being brought up later on in the 2 day interval http://www.ris.ripe.net/cgi-bin/bgplay.cgi?prefix=58.65.238.0/24&start=2008-09-05+01:15&end=2008-09-07+01:15 > -Tk > > -christian From randy at psg.com Sun Sep 7 02:18:21 2008 From: randy at psg.com (Randy Bush) Date: Sun, 07 Sep 2008 19:18:21 +1200 Subject: BCP38 dismissal In-Reply-To: <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> Message-ID: <48C3803D.3070402@psg.com> Jo Rhett wrote: > On Sep 4, 2008, at 7:24 AM, James Jun wrote: >> Indeed... In today's internet, protecting your own box (cp-policer/control >> plane filtering) is far more important IMO than implementing BCP38 >> when much >> of attack traffic comes from legitimate IP sources anyway (see botnets). > I'm sorry, but nonsense statements such as these burn the blood. Sure, > yes, protecting yourself is so much more important than protecting > anyone else. > > Anyone else want to stand up and join the "I am an asshole" club? normally i would have just hit delete. but your ad hominem attack on the messenger need a response. the reality of life is that he is correct in that "attack traffic comes from legitimate IP sources anyway." therefore, your first duty should be to keep your hosts from joining the massive army of botnets. randy From randy at psg.com Sun Sep 7 02:43:41 2008 From: randy at psg.com (Randy Bush) Date: Sun, 07 Sep 2008 19:43:41 +1200 Subject: an effect of ignoring BCP38 In-Reply-To: <20080905052227.GA8309@vacation.karoshi.com.> References: <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> <3861BD57-759F-4EE5-A274-DBCDE7F7485B@ianai.net> <20080905052227.GA8309@vacation.karoshi.com.> Message-ID: <48C3862D.6020200@psg.com> > http://www.caida.org/workshops/wide/0808/slides/measuring_reverse_paths.pdf great work on a tough problem randy From russ at intercage.com Sun Sep 7 03:32:48 2008 From: russ at intercage.com (InterCage - Russ) Date: Sun, 7 Sep 2008 01:32:48 -0700 Subject: InterCage, Inc. (NOT Atrivo) Message-ID: <12A7243745004CF880DEA8DDC5D7BFC5@NOCMOBILE> Hello Everyone, Good morning. Seeing the activity in regards to our company here at NANOG, I believe this is the most reasonable and responsible place to respond to the current issues on our network. We hope to obtain non-bias opinion's and good honest and truthful information from the users here. Being that there are much larger operators here then us, what kind of insight can you give to the issues that have arisen? We've near completely removed (completion monday 09/08/08) Hostfresh from our network. 2 of their /24's have been removed: 58.65.238.0/24 dropped 58.65.239.0/24 dropped The machine's they leased from us have been canceled. What do you suggest for the next move? Thank you for your time. Have a great day. --- Russell M. InterCage, Inc. From sam_mailinglists at spacething.org Sun Sep 7 03:36:45 2008 From: sam_mailinglists at spacething.org (Sam Stickland) Date: Sun, 07 Sep 2008 09:36:45 +0100 Subject: Cisco uRPF failures In-Reply-To: <5188BB8F-8EFC-4FCA-BA9F-E36E6C3CEB81@netconsonance.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <00c401c9072b$f46a38c0$dd3eaa40$@com> <007401c90e25$6eaf2280$4c0d6780$@com> <6bb5f5b10809031906m67c18854nb4fe7260ad3e153@mail.gmail.com> <5188BB8F-8EFC-4FCA-BA9F-E36E6C3CEB81@netconsonance.com> Message-ID: <48C3929D.4020009@spacething.org> Jo Rhett wrote: > That's the surprising thing -- no scenario. Very basic > configuration. Enabling uRPF and then hitting it with a few gig of > non-routable packets consistently caused the sup module to stop > talking on the console, and various other problems to persist > throughout the unit, ie no arp response. We were able to simulate > this with two 2 pc's direction connected to a 6500 in a lab. If I > remember right, we had to enable CEF to see the problem, but since CEF > is a kitchen sink that dozens of other features require you simply > couldn't disable it. Definately sounds like it could be a problem - I'd like to try and replicate this. What do you mean by non-routable traffic - traffic whose destination has no route (I assume you are running defaultless), or traffic that fails the uRPF check? And correct me if I'm wrong but I thought you can't disable CEF on the 6500 platform? hs-6513-1#conf t Enter configuration commands, one per line. End with CNTL/Z. hs-6513-1(config)#no ip cef % Incomplete command. hs-6513-1(config)#no ip cef ? accounting Enable CEF accounting distributed Distributed Cisco Express Forwarding event-log CEF event log commands interface CEF linecard commands linecard CEF linecard commands load-sharing Load sharing nsf Set CEF non-stop forwarding (NSF) characteristics table Set CEF forwarding table characteristics traffic-statistics Enable collection of traffic statistics hs-6513-1(config)#no ip cef distributed %Cannot disable CEF on this platform hs-6513-1(config)#exit hs-6513-1#sh version | inc IOS IOS (tm) s72033_rp Software (s72033_rp-ADVENTERPRISEK9_WAN-M), Version 12.2(18)SXF11, RELEASE SOFTWARE (fc1) Sam From brandon at rd.bbc.co.uk Sun Sep 7 06:51:35 2008 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Sun, 7 Sep 2008 12:51:35 +0100 (BST) Subject: only WV FIBER now peering with Atrivo / Intercage Message-ID: <200809071151.MAA21429@sunf10.rd.bbc.co.uk> > > Anton's post that GX is still providing them transit is a bit curious, since > > I was under the impression GX had severed all ties with Atrivo. But the > > table does not lie, a path of "174 3549 27595" is clearly transit. GX, care > > to comment? > > After poking for a bit, it's unclear what, if anything, GX is or isn't > doing here. Does it matter? The implication of this thread is the imposition of an internet death penalty on this AS. In which case people will have to hound each AS they're seen behind, whatever they're providing, and that will change as they run for cover. This seems a change of tactic from just null routing people you don't like on your own network brandon From trelane at trelane.net Sun Sep 7 07:16:02 2008 From: trelane at trelane.net (Andrew D Kirch) Date: Sun, 07 Sep 2008 08:16:02 -0400 Subject: only WV FIBER now peering with Atrivo / Intercage In-Reply-To: <200809071151.MAA21429@sunf10.rd.bbc.co.uk> References: <200809071151.MAA21429@sunf10.rd.bbc.co.uk> Message-ID: <48C3C602.2060203@trelane.net> Brandon Butterworth wrote: >>> Anton's post that GX is still providing them transit is a bit curious, since >>> I was under the impression GX had severed all ties with Atrivo. But the >>> table does not lie, a path of "174 3549 27595" is clearly transit. GX, care >>> to comment? >>> >> After poking for a bit, it's unclear what, if anything, GX is or isn't >> doing here. >> > > Does it matter? The implication of this thread is the imposition of an > internet death penalty on this AS. I vote yea. From swm at emanon.com Sun Sep 7 08:58:59 2008 From: swm at emanon.com (Scott Morris) Date: Sun, 7 Sep 2008 09:58:59 -0400 Subject: BGP Clueful from Windstream/Alltel? (Resend-addendum) Message-ID: <000a01c910f1$e0b7bb70$800610ac@scott66ed7b03d> Is there anyone hanging around here who happens to either be or can get me in touch with a BGP-clueful person at Windstream/Alltel (AS7029)??? Unicast would be great, I hate to tie up the list with this, but the standard prescribed methods haven't worked in 72 hours now... Sorry for the resend, but if you could contact me at ccie.4713 at gmail.com that will be much easier! Any emails to the subscribed address here won't work, which is the problem I'm attempting to solve with Windstream! :) Thanks in advance! Scott Morris swm at emanon.com From dnewman at networktest.com Sun Sep 7 09:23:07 2008 From: dnewman at networktest.com (David Newman) Date: Sun, 07 Sep 2008 07:23:07 -0700 Subject: Force10 Gear Message-ID: <48C3E3CB.4070009@networktest.com> Paul Wall wrote: > Once upon a time, vendors released products which relied on CPU-based > "flow" setup. Certain vintages of Cisco, Extreme, Foundry, > Riverstone, etc come to mind. These could forward at "line rate" > under normal conditions. Sufficient randomization on the sources > and/or destinations (DDoS, Windows worm, portscans, ...) and they'd > die a spectacular death. Nowadays, this is less of a concern, as the > higher-end boxes can program a full routing table (and then some) > worth of prefixes in CAM. > > Either way, I think it's a good test metric. I'd be interested in > hearing of why you think that's not the case. Back on topic, doing a > couple of gigs of traffic at line rate is a walk in the park for any > modern product billed as a "layer 3 switch". The differentiator > between, say, a Dell and a Cisco, is in the software and profoundly > not the forwarding performance. Without disagreeing with your main point, there are still plenty of ways to bring even very large boxes to near-zero forwarding rates: 1. Set IP options. A pair of Cat 6509Es using VSS can forward packets without options at up to 770 mpps, but when packets have options the maximum is more like 20 kpps. And that's a "high-speed" example; the options forwarding rate is more like 0 pps with some other devices. Silicon that forwards packets very fast is only good when header lengths are fixed. 2. Use weak hashing algorithms. Some switches (names removed to protect the guilty) hash on the low-order three bits of MAC address to decide which of eight ASICs will forward a packet. I have heard of, but have not tested, devices that use only three bits for making OSPF ECMP decisions. Not surprisingly either technique can lead to lots of hash collisions in routed environments. 3. Offer IP multicast. Maximum forwarding rates for multicast are rather different than IP unicast with some vendors' implementations, and may be affected by group count, mroute count and amount of replication. dn From danny at tcb.net Sun Sep 7 09:56:12 2008 From: danny at tcb.net (Danny McPherson) Date: Sun, 7 Sep 2008 08:56:12 -0600 Subject: only WV FIBER now peering with Atrivo / Intercage In-Reply-To: References: <620fd17c0809061027t61094de9j5df248c313c6638b@mail.gmail.com> <769EDE41-DD8B-419D-B79D-C644AC5A8E2A@ianai.net> <2e9d8ae50809061730n6e9a9279nad989b1fe7d00e85@mail.gmail.com> Message-ID: <104189B8-6A09-4020-9D42-95F132B8F6BA@tcb.net> I'm not sure where that 58.65.238.0/24 prefix with AS3549 in the path came from. I *currently* see no BGP RIB entries with AS "3549_27595" (GBLX Intercage) in the path. A query for the past 6 hours yields 32 AS 27595 originated prefixes, here are each with their associated upstream ASN(s) (26769::BANDCON, 19151::WVFIBER-1): 58.65.238.0/24 - 26769 58.65.239.0/24 - 26769 64.28.176.0/20 - 26769,19151 67.210.0.0/21 - 26769,19151 67.210.8.0/22 - 26769,19151 67.210.14.0/23 - 26769,19151 69.22.162.0/23 - 26769,19151 69.22.168.0/21 - 26769,19151 69.22.184.0/22 - 26769,19151 69.31.64.0/20 - 26769,19151 69.50.160.0/19 - 26769,19151 69.50.173.0/24 - 26769,19151 69.50.182.0/23 - 26769,19151 85.255.113.0/24 - 26769,19151 85.255.114.0/23 - 26769,19151 85.255.116.0/22 - 26769,19151 85.255.116.0/23 - 26769,19151 85.255.118.0/24 - 26769,19151 85.255.119.0/24 - 26769,19151 85.255.120.0/23 - 26769,19151 85.255.120.0/24 - 26769,19151 85.255.121.0/24 - 26769,19151 85.255.122.0/24 - 26769,19151 116.50.10.0/24 - 26769,19151 116.50.11.0/24 - 26769,19151 216.255.176.0/20 - 26769,19151 216.255.176.0/21 - 26769,19151 216.255.176.0/22 - 19151 216.255.180.0/22 - 19151 216.255.184.0/21 - 26769,19151 216.255.184.0/22 - 19151 216.255.188.0/22 - 19151 As for which of these prefixes seem to be associated with alleged nefarious activities, I'll leave that as an exercise for the operator. -danny From patrick at ianai.net Sun Sep 7 10:42:06 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 7 Sep 2008 11:42:06 -0400 Subject: only WV FIBER now peering with Atrivo / Intercage In-Reply-To: <48C3C602.2060203@trelane.net> References: <200809071151.MAA21429@sunf10.rd.bbc.co.uk> <48C3C602.2060203@trelane.net> Message-ID: <3BBF751E-267D-4D42-8FF1-79531448A47B@ianai.net> On Sep 7, 2008, at 8:16 AM, Andrew D Kirch wrote: > Brandon Butterworth wrote: >>>> Anton's post that GX is still providing them transit is a bit >>>> curious, since >>>> I was under the impression GX had severed all ties with Atrivo. >>>> But the >>>> table does not lie, a path of "174 3549 27595" is clearly >>>> transit. GX, care >>>> to comment? >>>> >>> After poking for a bit, it's unclear what, if anything, GX is or >>> isn't >>> doing here. >>> >> >> Does it matter? The implication of this thread is the imposition of >> an >> internet death penalty on this AS. > I vote yea. Seconded. (Thirded?) -- TTFN, patrick From adrian at creative.net.au Sun Sep 7 10:49:43 2008 From: adrian at creative.net.au (Adrian Chadd) Date: Sun, 7 Sep 2008 23:49:43 +0800 Subject: Force10 Gear In-Reply-To: <48C3E3CB.4070009@networktest.com> References: <48C3E3CB.4070009@networktest.com> Message-ID: <20080907154943.GA18741@skywalker.creative.net.au> On Sun, Sep 07, 2008, David Newman wrote: > 1. Set IP options. A pair of Cat 6509Es using VSS can forward packets > without options at up to 770 mpps, but when packets have options the > maximum is more like 20 kpps. And that's a "high-speed" example; the > options forwarding rate is more like 0 pps with some other devices. > Silicon that forwards packets very fast is only good when header lengths > are fixed. So what you're saying is "send the right crafted packets and DoS the internet", right? (I think I know which options may make routers go all software-path on the packets but I haven't given it a run on a Cat6500. Hm, I wonder if this here 3750 in the lab will do..) Adrian From patrick at ianai.net Sun Sep 7 10:58:16 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 7 Sep 2008 11:58:16 -0400 Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: <12A7243745004CF880DEA8DDC5D7BFC5@NOCMOBILE> References: <12A7243745004CF880DEA8DDC5D7BFC5@NOCMOBILE> Message-ID: On Sep 7, 2008, at 4:32 AM, InterCage - Russ wrote: > Seeing the activity in regards to our company here at NANOG, I > believe this is the most reasonable and responsible place to respond > to the current issues on our network. We hope to obtain non-bias > opinion's and good honest and truthful information from the users > here. > > Being that there are much larger operators here then us, what kind > of insight can you give to the issues that have arisen? > > We've near completely removed (completion monday 09/08/08) Hostfresh > from our network. 2 of their /24's have been removed: > 58.65.238.0/24 dropped > 58.65.239.0/24 dropped > The machine's they leased from us have been canceled. > > What do you suggest for the next move? A hearty pat on the back for a job well done. -- TTFN, patrick From tkapela at gmail.com Sun Sep 7 10:59:09 2008 From: tkapela at gmail.com (Anton Kapela) Date: Sun, 7 Sep 2008 10:59:09 -0500 Subject: only WV FIBER now peering with Atrivo / Intercage In-Reply-To: <3BBF751E-267D-4D42-8FF1-79531448A47B@ianai.net> References: <200809071151.MAA21429@sunf10.rd.bbc.co.uk> <48C3C602.2060203@trelane.net> <3BBF751E-267D-4D42-8FF1-79531448A47B@ianai.net> Message-ID: <2e9d8ae50809070859n2da168e1p292471fe56f387fa@mail.gmail.com> Sorry for the confusing as-paths, folks. As it happens, the AS174 update-group that my upstream was peered within stopped transporting updates sometime yesterday. A Cogent engineer was able to fix what appears to be an IOS bug shortly after I sent my note yesterday. -Tk On 9/7/08, Patrick W. Gilmore wrote: > On Sep 7, 2008, at 8:16 AM, Andrew D Kirch wrote: >> Brandon Butterworth wrote: >>>>> Anton's post that GX is still providing them transit is a bit >>>>> curious, since >>>>> I was under the impression GX had severed all ties with Atrivo. >>>>> But the >>>>> table does not lie, a path of "174 3549 27595" is clearly >>>>> transit. GX, care >>>>> to comment? >>>>> >>>> After poking for a bit, it's unclear what, if anything, GX is or >>>> isn't >>>> doing here. >>>> >>> >>> Does it matter? The implication of this thread is the imposition of >>> an >>> internet death penalty on this AS. >> I vote yea. > > Seconded. (Thirded?) > > -- > TTFN, > patrick > > > From patrick at ianai.net Sun Sep 7 10:59:35 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 7 Sep 2008 11:59:35 -0400 Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: References: <12A7243745004CF880DEA8DDC5D7BFC5@NOCMOBILE> Message-ID: <638B39AB-4B16-4BA9-9CFD-DDD95A128AA5@ianai.net> On Sep 7, 2008, at 11:58 AM, Patrick W. Gilmore wrote: > On Sep 7, 2008, at 4:32 AM, InterCage - Russ wrote: > >> Seeing the activity in regards to our company here at NANOG, I >> believe this is the most reasonable and responsible place to >> respond to the current issues on our network. We hope to obtain non- >> bias opinion's and good honest and truthful information from the >> users here. >> >> Being that there are much larger operators here then us, what kind >> of insight can you give to the issues that have arisen? >> >> We've near completely removed (completion monday 09/08/08) >> Hostfresh from our network. 2 of their /24's have been removed: >> 58.65.238.0/24 dropped >> 58.65.239.0/24 dropped >> The machine's they leased from us have been canceled. >> >> What do you suggest for the next move? > > A hearty pat on the back for a job well done. P.S. And removing you from the "will _not_ buy from" list of providers. -- TTFN, patrick From dnewman at networktest.com Sun Sep 7 12:00:26 2008 From: dnewman at networktest.com (David Newman) Date: Sun, 07 Sep 2008 10:00:26 -0700 Subject: Force10 Gear In-Reply-To: <20080907154943.GA18741@skywalker.creative.net.au> References: <48C3E3CB.4070009@networktest.com> <20080907154943.GA18741@skywalker.creative.net.au> Message-ID: <48C408AA.2090904@networktest.com> On 9/7/08 8:49 AM, Adrian Chadd wrote: > On Sun, Sep 07, 2008, David Newman wrote: > >> 1. Set IP options. A pair of Cat 6509Es using VSS can forward packets >> without options at up to 770 mpps, but when packets have options the >> maximum is more like 20 kpps. And that's a "high-speed" example; the >> options forwarding rate is more like 0 pps with some other devices. >> Silicon that forwards packets very fast is only good when header lengths >> are fixed. > > So what you're saying is "send the right crafted packets and DoS the internet", > right? My experience *in lab testing* is that most and perhaps all switches do slow-path processing of v4 and v6 packets with IP options set, and that slow-path forwarding rates are a tiny fraction of fast-path forwarding rates. Christian Huitema made a similar observation in one of his textbooks 10 or more years ago; tests as recently as this year suggest this is still the case. I'm not making any assertions about DoS attacks on production networks. Rate controls and other mechanisms can help mitigate the effects of flooding attacks, but that's a different topic. > (I think I know which options may make routers go all software-path on the > packets but I haven't given it a run on a Cat6500. Hm, I wonder if this here > 3750 in the lab will do..) The record route option will cause rather precipitous drops in forwarding rates on both boxes (and many others). I have not tried other option types, but other testers have told me these too will be slow-pathed. Again, from the ASIC/NP/FPGA's standpoint: Fixed-length, good. Variable-length, not so much... dn From eugen at imacandi.net Sun Sep 7 13:30:28 2008 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Sun, 7 Sep 2008 21:30:28 +0300 Subject: ingress SMTP In-Reply-To: References: <20080903151617.A14277808@relayer.avian.org> Message-ID: <67F8D38E-3173-4B10-8962-EA3DD6E90C26@imacandi.net> On Sep 3, 2008, at 6:52 PM, Tim Sanderson wrote: > Anybody not wanting to use their ISP email would notice it. I see > filtering 25 FROM the customer as something that is not likely to > happen because of this. When a customer buys bandwidth, they want to > be able to use it for whatever they choose. This would be just one > more restriction giving competitive advantage to any ISP not doing > the filtering. > In my country, some ISPs block outbound SMTP for home users and they require those users to use the ISPs SMTP server for outgoing which happen to do antivirus and antispam filtering. They will unblock port 25 if you provide good and rational explanation why you need it open and that you understand that in case of problems you will be held responsible. Eugen. From eugen at imacandi.net Sun Sep 7 15:38:36 2008 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Sun, 7 Sep 2008 23:38:36 +0300 Subject: ingress SMTP In-Reply-To: References: Message-ID: <2CAF61E4-FF0E-4B1A-AA84-6708913862D8@imacandi.net> On Sep 3, 2008, at 8:08 PM, Winders, Timothy A wrote: > > Yes, setting up a 587 submit server internally would be best, but > man power > is at a premium and it hasn't happened. > I don't know what SMTP server you're using, but on Postfix you just need to uncomment one line in master.cf, do a reload and that's it. it takes less than a minute to do it on server. YMMV. From buc at visi.com Sun Sep 7 15:58:15 2008 From: buc at visi.com (Bradley Urberg-Carlson, VISI) Date: Sun, 07 Sep 2008 15:58:15 -0500 Subject: 10GE CWDM In-Reply-To: <1220316646_267033@mail1.tellurian.net> References: <922203.27764.qm@web65506.mail.ac4.yahoo.com> <53A6C7E936ED8544B1A2BC990D254F942EA6F7697F@MEMEXG1.HOST.local> <1220316646_267033@mail1.tellurian.net> Message-ID: On Mon, 01 Sep 2008 20:50:46 -0400 Robert Boyle wrote: > The only affordable CWDM 10G system I have seen although I haven't used it yet > is a single 10G band at 1310 or 1550 with 8 additional 2.5G bands around it. I've wondered if one could shoot with DWDM 10G optics into two channels of a CWDM mux. For example, by connecting DWDM channel 359 (center 1530.33 nm) and 334 (center 1550.12 nm) to the 1530/1550 filters of a CWDM mux with 20nm spacing (+/- 6.5nm pass band). Might that support 1x10gig + 3x1gig on a single strand, or 2x10G + 6x1G on a pair? (and no, I haven't tried it). Bradley From mike at mtcc.com Sun Sep 7 16:31:50 2008 From: mike at mtcc.com (Michael Thomas) Date: Sun, 07 Sep 2008 14:31:50 -0700 Subject: ingress SMTP In-Reply-To: <2CAF61E4-FF0E-4B1A-AA84-6708913862D8@imacandi.net> References: <2CAF61E4-FF0E-4B1A-AA84-6708913862D8@imacandi.net> Message-ID: <48C44846.8050308@mtcc.com> Eugeniu Patrascu wrote: > > On Sep 3, 2008, at 8:08 PM, Winders, Timothy A wrote: > >> >> Yes, setting up a 587 submit server internally would be best, but man >> power >> is at a premium and it hasn't happened. >> > > I don't know what SMTP server you're using, but on Postfix you just > need to uncomment one line in master.cf, do a reload and that's it. it > takes less than a minute to do it on server. YMMV. Would that it were so easy :) You also have the more daunting task of hooking up your auth/aaa infrastructure with your MTA's, and all of the care and feeding that entails. Mike From truman at suspicious.org Sun Sep 7 16:43:38 2008 From: truman at suspicious.org (Truman Boyes) Date: Sun, 7 Sep 2008 17:43:38 -0400 Subject: ingress SMTP In-Reply-To: <48C44846.8050308@mtcc.com> References: <2CAF61E4-FF0E-4B1A-AA84-6708913862D8@imacandi.net> <48C44846.8050308@mtcc.com> Message-ID: <9A57D45A-5348-490E-9FEE-1A945EE5C5EE@suspicious.org> On 7/09/2008, at 5:31 PM, Michael Thomas wrote: > Eugeniu Patrascu wrote: >> >> On Sep 3, 2008, at 8:08 PM, Winders, Timothy A wrote: >> >>> >>> Yes, setting up a 587 submit server internally would be best, but >>> man power >>> is at a premium and it hasn't happened. >>> >> >> I don't know what SMTP server you're using, but on Postfix you just >> need to uncomment one line in master.cf, do a reload and that's it. >> it takes less than a minute to do it on server. YMMV. > Would that it were so easy :) You also have the more daunting task > of hooking up your auth/aaa infrastructure with your MTA's, and all > of the care and feeding that entails. > > Mike Exactly. The binding to port 587 is the easy part. The authentication / TLS setup is slightly more complex in most networks. This usually requires the running of another daemon on your MTA or another reachable host in your network, which takes some time to get up and running. Secondly you likely want to use a signed certificate for your port 587 TLS connections, which means going through the cert signing process with a CA. Truman From eugen at imacandi.net Sun Sep 7 16:51:15 2008 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Mon, 8 Sep 2008 00:51:15 +0300 Subject: ingress SMTP In-Reply-To: <48C44846.8050308@mtcc.com> References: <2CAF61E4-FF0E-4B1A-AA84-6708913862D8@imacandi.net> <48C44846.8050308@mtcc.com> Message-ID: <2B638B5A-CF6B-4018-B8FB-E96F16A7B039@imacandi.net> On Sep 8, 2008, at 12:31 AM, Michael Thomas wrote: > Eugeniu Patrascu wrote: >> >> On Sep 3, 2008, at 8:08 PM, Winders, Timothy A wrote: >> >>> >>> Yes, setting up a 587 submit server internally would be best, but >>> man power >>> is at a premium and it hasn't happened. >>> >> >> I don't know what SMTP server you're using, but on Postfix you just >> need to uncomment one line in master.cf, do a reload and that's it. >> it takes less than a minute to do it on server. YMMV. > Would that it were so easy :) You also have the more daunting task > of hooking up your auth/aaa infrastructure with your MTA's, and all > of the care and feeding that entails. > IIRC the OP said that he was already doing AUTH on port 25, and this was the basis for my email stating it's quite easy. From twinders at southplainscollege.edu Sun Sep 7 16:54:28 2008 From: twinders at southplainscollege.edu (Winders, Timothy A) Date: Sun, 07 Sep 2008 16:54:28 -0500 Subject: ingress SMTP In-Reply-To: <2B638B5A-CF6B-4018-B8FB-E96F16A7B039@imacandi.net> Message-ID: On 9/7/08 4:51 PM, "Eugeniu Patrascu" wrote: > > On Sep 8, 2008, at 12:31 AM, Michael Thomas wrote: > >> Eugeniu Patrascu wrote: >>> >>> On Sep 3, 2008, at 8:08 PM, Winders, Timothy A wrote: >>> >>>> >>>> Yes, setting up a 587 submit server internally would be best, but >>>> man power >>>> is at a premium and it hasn't happened. >>>> >>> >>> I don't know what SMTP server you're using, but on Postfix you just >>> need to uncomment one line in master.cf, do a reload and that's it. >>> it takes less than a minute to do it on server. YMMV. >> Would that it were so easy :) You also have the more daunting task >> of hooking up your auth/aaa infrastructure with your MTA's, and all >> of the care and feeding that entails. >> > IIRC the OP said that he was already doing AUTH on port 25, and this > was the basis for my email stating it's quite easy. > Correct on all accounts. I got 587 up and running last week. Tim Winders | Associate Dean of Information Technology | South Plains College From frnkblk at iname.com Sun Sep 7 17:22:53 2008 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 7 Sep 2008 17:22:53 -0500 Subject: Force10 Gear In-Reply-To: <48C3E3CB.4070009@networktest.com> References: <48C3E3CB.4070009@networktest.com> Message-ID: I think it would be interesting to put a table of routing devices together along with the commands it takes to knock down their forwarding rates. And to find out what platform has the higher percentage drop in forwarding rate. As mentioned elsewhere, it's not the pps, but operations per second. Frank -----Original Message----- From: David Newman [mailto:dnewman at networktest.com] Sent: Sunday, September 07, 2008 9:23 AM To: nanog at nanog.org Subject: Re: Force10 Gear Paul Wall wrote: > Once upon a time, vendors released products which relied on CPU-based > "flow" setup. Certain vintages of Cisco, Extreme, Foundry, > Riverstone, etc come to mind. These could forward at "line rate" > under normal conditions. Sufficient randomization on the sources > and/or destinations (DDoS, Windows worm, portscans, ...) and they'd > die a spectacular death. Nowadays, this is less of a concern, as the > higher-end boxes can program a full routing table (and then some) > worth of prefixes in CAM. > > Either way, I think it's a good test metric. I'd be interested in > hearing of why you think that's not the case. Back on topic, doing a > couple of gigs of traffic at line rate is a walk in the park for any > modern product billed as a "layer 3 switch". The differentiator > between, say, a Dell and a Cisco, is in the software and profoundly > not the forwarding performance. Without disagreeing with your main point, there are still plenty of ways to bring even very large boxes to near-zero forwarding rates: 1. Set IP options. A pair of Cat 6509Es using VSS can forward packets without options at up to 770 mpps, but when packets have options the maximum is more like 20 kpps. And that's a "high-speed" example; the options forwarding rate is more like 0 pps with some other devices. Silicon that forwards packets very fast is only good when header lengths are fixed. 2. Use weak hashing algorithms. Some switches (names removed to protect the guilty) hash on the low-order three bits of MAC address to decide which of eight ASICs will forward a packet. I have heard of, but have not tested, devices that use only three bits for making OSPF ECMP decisions. Not surprisingly either technique can lead to lots of hash collisions in routed environments. 3. Offer IP multicast. Maximum forwarding rates for multicast are rather different than IP unicast with some vendors' implementations, and may be affected by group count, mroute count and amount of replication. dn From matthew at sorbs.net Sun Sep 7 17:27:52 2008 From: matthew at sorbs.net (matthew at sorbs.net) Date: Mon, 08 Sep 2008 08:27:52 +1000 Subject: ingress SMTP Message-ID: <1f4b5564.55641f4b@sorbs.net> ----- Original Message ----- From: Michael Thomas Date: Monday, September 8, 2008 7:31 am Subject: Re: ingress SMTP > > Would that it were so easy :) You also have the more daunting task > of hooking up your auth/aaa infrastructure with your MTA's, and all > of the care and feeding that entails. As a matter of interest, it took but a couple of person hours to sort this out at my last place of work, the largest time chunk in equation was the compiling of TLS and the various SASL modules into Postfix. The second from largest chunk of time was to get the script to get the information required from the various other back end mail servers on campus, including, but not limited to, Lotus Notes, M$ Exchange, and Sun/iPlanet messaging server and it's LDAP server. The only down side to the system was password changed took up to 15 minutes to get to the mail systems as there was no direct connection between the external gateways and the internal auth systems. Of course the above doesn't take into account the several weeks of political badgering and grandstanding that we endured to get the faculties to actually accept that that was the way it was going to be. They couldn't stand that there would only be incoming and outgoing mail via the central gateway. Such is life at Universities. Regards, M From mpetach at netflight.com Sun Sep 7 17:41:37 2008 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 7 Sep 2008 15:41:37 -0700 Subject: Force10 Gear In-Reply-To: References: <48C3E3CB.4070009@networktest.com> Message-ID: <63ac96a50809071541k61b3e3d4re1d6d08adb55d121@mail.gmail.com> On 9/7/08, Frank Bulk wrote: > I think it would be interesting to put a table of routing devices together along with the commands it takes to knock down their forwarding rates. And to find out what platform has the higher percentage drop in forwarding rate. > > As mentioned elsewhere, it's not the pps, but operations per second. Send a 3kpps stream of multicast packets with TTL=1 towards a sup720 and you can watch it keel over and cry uncle. It really, really doesn't take much these days to kill high-end hardware; they're so optimized for a specific class of traffic that they handle well in hardware, as that's what the bulk of the normal traffic is, and that's what the marketing department needs to chase to keep up with the competition; any traffic profile outside of that doesn't get the same focus from the hardware forwarding teams because that's not where the pressure to keep up from the marketplace is coming from. *Nobody* goes out and says "I have $10M to spend on routers, but to qualify they must be able to forward 10Mpps of IPv4 packets with IP options enabled, sustained rate, with no loss". That's just not a driving market force right now. I think you would find that your table simply reflects what the *bulk* of the traffic profiles from major customers represent; those areas that cause the routers pain in terms of forwarding are exactly those traffic patterns that are *not* highly represented among the majority of the customer base. Matt From mike at mtcc.com Sun Sep 7 18:39:25 2008 From: mike at mtcc.com (Michael Thomas) Date: Sun, 07 Sep 2008 16:39:25 -0700 Subject: ingress SMTP In-Reply-To: <1f4b5564.55641f4b@sorbs.net> References: <1f4b5564.55641f4b@sorbs.net> Message-ID: <48C4662D.7050002@mtcc.com> matthew at sorbs.net wrote: > ----- Original Message ----- > From: Michael Thomas > Date: Monday, September 8, 2008 7:31 am > Subject: Re: ingress SMTP > >> Would that it were so easy :) You also have the more daunting task >> of hooking up your auth/aaa infrastructure with your MTA's, and all >> of the care and feeding that entails. >> > > As a matter of interest, it took but a couple of person hours to sort > this out at my last place of work, the largest time chunk in equation > was the compiling of TLS and the various SASL modules into Postfix. The > second from largest chunk of time was to get the script to get the > information required from the various other back end mail servers on > campus, including, but not limited to, Lotus Notes, M$ Exchange, and > Sun/iPlanet messaging server and it's LDAP server. The only down side > to the system was password changed took up to 15 minutes to get to the > mail systems as there was no direct connection between the external > gateways and the internal auth systems. > > Of course the above doesn't take into account the several weeks of > political badgering and grandstanding that we endured to get the > faculties to actually accept that that was the way it was going to be. > They couldn't stand that there would only be incoming and outgoing mail > via the central gateway. Such is life at Universities. > I don't have any experience in ISP or university environments, but when we were trying to get DKIM running at Cisco, we thought that it would be a whole lot better idea to at least have an idea who was sending the mail if we were going to sign it as being ours. This proved to be quite a bit more problematic than we imagined, owing partly to getting the responsible group to want to take ownership to make the change (we worked closely with them, and they were receptive), but much more of not knowing what we didn't know were we to require smtp auth on submission or anywhere else for that matter. This may speak more to the way that the big old franken-company's parts were put together, but I suspect that it's probably a pretty common problem for any sort of company that's, oh say, grown fast, or has lots of things going on, or where one hand doesn't know what the other is doing :) This is pretty much similar to DKIM itself: it's pretty easy to get the bulk of your traffic doing the right thing, but it's pretty hard to get the outliers brought in line such that you can make a strong policy statement in the case of DKIM (cf draft-ietf-dkim-asp) or rejecting unauthenticated traffic via 587, or whatever else. Mike From eddy+public+spam at noc.everquick.net Sun Sep 7 18:47:31 2008 From: eddy+public+spam at noc.everquick.net (Edward B. DREGER) Date: Sun, 7 Sep 2008 23:47:31 +0000 (GMT) Subject: ingress SMTP In-Reply-To: <48BEB3C3.1070600@gravityfree.com> References: <20080903151617.A14277808@relayer.avian.org> <48BEB3C3.1070600@gravityfree.com> Message-ID: JS> Date: Wed, 03 Sep 2008 11:56:51 -0400 JS> From: Justin Scott JS> Have you ever tried to have Joe Sixpack call BigISP support to ask JS> for an exception to a port block on his consumer-class connection JS> with a dynamic IP? In my experience, most people capable of preventing outbound 25/TCP abuse also are capable of requesting "please allow me unfiltered 25/TCP access to the entire world". 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 blackham at gmail.com Sun Sep 7 19:31:42 2008 From: blackham at gmail.com (Kevin Blackham) Date: Sun, 7 Sep 2008 18:31:42 -0600 Subject: 10GE CWDM In-Reply-To: References: <922203.27764.qm@web65506.mail.ac4.yahoo.com> <53A6C7E936ED8544B1A2BC990D254F942EA6F7697F@MEMEXG1.HOST.local> <1220316646_267033@mail1.tellurian.net> Message-ID: CWDM filter bandpass is wide to allow for drifting optics. Anything within about 7nm of 1530/1550 should work fine. I've got some optics near 34 and 59 on order to do exactly that in a bidir single fiber arrangement. I'll report back my results. On 9/7/08, Bradley Urberg-Carlson, VISI wrote: > On Mon, 01 Sep 2008 20:50:46 -0400 > Robert Boyle wrote: > > The only affordable CWDM 10G system I have seen although I haven't > used it yet > > is a single 10G band at 1310 or 1550 with 8 additional 2.5G bands > around it. > I've wondered if one could shoot with DWDM 10G optics into two channels > of a CWDM mux. For example, by connecting DWDM channel 359 (center > 1530.33 nm) and 334 (center 1550.12 nm) to the 1530/1550 filters of a > CWDM mux with 20nm spacing (+/- 6.5nm pass band). Might that support > 1x10gig + 3x1gig on a single strand, or 2x10G + 6x1G on a pair? (and > no, I haven't tried it). > Bradley > -- Sent from Gmail for mobile | mobile.google.com From hobbit at avian.org Sun Sep 7 18:53:51 2008 From: hobbit at avian.org (*Hobbit*) Date: Sun, 7 Sep 2008 23:53:51 +0000 (GMT) Subject: Force10 Gear Message-ID: <20080907235351.1457A7808@relayer.avian.org> This once again quickly reduces to a question of real-life need in my mind. What proportion of useful traffic actually carries IP options these days? Who uses them other than fooling around with the occasional source-routing or RR exercise, if their local infrastructure even permits it to be sent? Many sites just firewall off all that stuff because in real life they never use it or need it. For them it's more trouble than it would be worth trying to process correctly, especially in a security context, so that's their accepted real-life practice. Clearly, those who design the routing iron are well aware of such practice because they optimized the hardware to process the far more typical no-options day to day traffic. While they still accomodate options it's evidently done as kind of an add-on bandaid way outside of the normal path. Now you have to ask yourself where the people making the iron cheaped out -- should they have designed in the ability to handle all these corner cases at their normal wire speed, or should they have dismissed such foolishness and concentrated on what they knew the industry actually requires? How much additional cost does anyone think ASICs to deal with options and other seldom- seen conditions at the same transit rates would incur? I think the most common answer would be "f'geddaboudit". The TTL=1 is an interesting one, but really, under normal conditions shouldn't happen that often. People tracerouting certainly shouldn't expect 100% reliability on getting the "expired" ICMP back, and automatically throttling the rate of errors from routing loops might have certain benefits so why try to handle *every* expired TTL that comes along? It seems like taking anything out of the fast-path should only be done if the slow path is good and ready to accept it, and if someone's trying to hammer the box with stupid stuff then most of it should simply be dropped. Handling it should be near the bottom of the main processor's priority list ... and rather than allow the fast iron to pile way too much crap in its inbox to be dealt with, process-switching should have a VERY short queue and be able to tell the lower levels "not now" and simply increment some obscure counter for "stupid packets dropped" without letting that impinge on the more important tasks at hand. Having the whole box fall over is the *least* acceptable result. _H* From alex at pilosoft.com Sun Sep 7 22:21:53 2008 From: alex at pilosoft.com (Alex Pilosov) Date: Sun, 7 Sep 2008 23:21:53 -0400 (EDT) Subject: 10GE CWDM In-Reply-To: Message-ID: On Sun, 7 Sep 2008, Bradley Urberg-Carlson, VISI wrote: > I've wondered if one could shoot with DWDM 10G optics into two channels > of a CWDM mux. For example, by connecting DWDM channel 359 (center > 1530.33 nm) and 334 (center 1550.12 nm) to the 1530/1550 filters of a > CWDM mux with 20nm spacing (+/- 6.5nm pass band). Might that support > 1x10gig + 3x1gig on a single strand, or 2x10G + 6x1G on a pair? (and > no, I haven't tried it). Yes, that'll work fine. You can also use DWDM mux to mux down 1529.53/1530.33/1531.13 and put them all into 1530 channel. (Same with 1550 channels). http://www.nanog.org/meetings/nanog38/presentations/pilosov.pdf http://www.nanog.org/meetings/nanog37/presentations/4-pilosov.pdf From ge at linuxbox.org Sun Sep 7 23:22:21 2008 From: ge at linuxbox.org (Gadi Evron) Date: Sun, 7 Sep 2008 23:22:21 -0500 (CDT) Subject: [funsec] Security Fix: Updates on Atrivo/Intercage (fwd) Message-ID: ---------- Forwarded message ---------- Date: Mon, 8 Sep 2008 04:17:29 GMT From: Paul Ferguson To: funsec at linuxbox.org Subject: [funsec] Security Fix: Updates on Atrivo/Intercage -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Krebs add some late updates to his "Security Fix" article from Friday 5 September 2008: [snip] Update, Sunday, Sept. 7, 8:02 p.m.: I spoke today with Randy Epstein, president of WVFiber and co-founder of Host.net, which acquired WVFiber just six weeks ago. Epstein said after reading reports from Security Fix, Hostexploit.com, Spamhaus.org and others about cyber crime activities at Atrivo, WVFiber has decided to drop Atrivo as a customer. WVFiber plans to stop providing upstream connectivity to Atrivo by Wednesday or Thursday at the latest, Epstein said. That would leave Atrivo with just a single upstream provider -- Bandcon. Update, Sunday, Sept. 7, 9:15 p.m.: nLayer Communications, a company that owns a significant slice of the Internet addresses used by Atrivo/Intercage, is demanding that Atrivo vacate the space and return the addresses by Sept 30. "Atrivo/Intercage has not been a direct customer of nLayer Communications since December 2007, but they still have some legacy reallocations from our IP space," wrote nLayer co-founder Richard A. Steenbergen, in an e-mail to Security Fix. "Since they are no longer a customer, we require that they return our non-portable IP space, and have given them a deadline of September 30th to do so. If the IP space is not returned by that point, we will follow standard procedure to reclaim it, including null routing the space, and sending cease and desist letters to any network who still transits it without our permission." According to Steenbergen, Atrivo/Intercage must return roughly 7,400 IP addresses. [snip] Ref: http://voices.washingtonpost.com/securityfix/2008/09/scam-heavy_us_isp_grow s_more_i.html FYI, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFIxKdMq1pz9mNUZTMRAnLcAKCRgGjZrgwr5xCmFFXPV/a0xUAlVwCaAkPL nHo38nvc5azHws2QPhshAvY= =zWoJ -----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. From bmanning at vacation.karoshi.com Mon Sep 8 00:40:30 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 8 Sep 2008 05:40:30 +0000 Subject: an effect of ignoring BCP38 In-Reply-To: <48C3862D.6020200@psg.com> References: <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> <3861BD57-759F-4EE5-A274-DBCDE7F7485B@ianai.net> <20080905052227.GA8309@vacation.karoshi.com.> <48C3862D.6020200@psg.com> Message-ID: <20080908054030.GA16241@vacation.karoshi.com.> On Sun, Sep 07, 2008 at 07:43:41PM +1200, Randy Bush wrote: > > http://www.caida.org/workshops/wide/0808/slides/measuring_reverse_paths.pdf > > great work on a tough problem > yes, but would it work if we all did BCP38 filtering? --bill From saku+nanog at ytti.fi Mon Sep 8 03:55:10 2008 From: saku+nanog at ytti.fi (Saku Ytti) Date: Mon, 8 Sep 2008 11:55:10 +0300 Subject: Cisco uRPF failures In-Reply-To: <5188BB8F-8EFC-4FCA-BA9F-E36E6C3CEB81@netconsonance.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <00c401c9072b$f46a38c0$dd3eaa40$@com> <007401c90e25$6eaf2280$4c0d6780$@com> <6bb5f5b10809031906m67c18854nb4fe7260ad3e153@mail.gmail.com> <5188BB8F-8EFC-4FCA-BA9F-E36E6C3CEB81@netconsonance.com> Message-ID: <20080908085510.GA27179@mx.ytti.net> On (2008-09-04 09:35 -0700), Jo Rhett wrote: > quickly, but that turns out not to be the case. To this day I've never > found a network operator using uRPF on Cisco gear. > (note: network operator. it's probably fine for several-hundred-meg > enterprise sites) To this day I've never met network operator not using uRPF on Cisco gear. (note: network operator. It's probably not used widely by enterprises) HOXBOX#sh run int ten4/1 Building configuration... Current configuration : 126 bytes ! interface TenGigabitEthernet4/1 no ip address no ip redirects no ip proxy-arp load-interval 30 hold-queue 4096 in end HOXBOX#sh run int ten4/1.42 Building configuration... Current configuration : 220 bytes ! interface TenGigabitEthernet4/1.42 encapsulation dot1Q 42 ip address 42.42.42.1 255.255.255.0 ip verify unicast source reachable-via rx allow-default no ip redirects no ip proxy-arp no snmp trap link-status end HOXBOX#debug ip cef drops rate 5 IP CEF drops debugging is on rate 5 HOXBOX#term mon HOXBOX# Sep 8 10:49:58.622 CEST: CEF-Drop: Packet from 103.63.17.0 (Te4/1.42) to 205.219.27.0, Verify Unicast Reverse-Path feature Sep 8 10:49:58.822 CEST: CEF-Drop: Packet from 121.215.245.0 (Te4/1.42) to 126.154.213.0, Verify Unicast Reverse-Path feature Sep 8 10:49:59.022 CEST: CEF-Drop: Packet from 150.38.77.0 (Te4/1.42) to 108.119.215.0, Verify Unicast Reverse-Path feature Sep 8 10:49:59.222 CEST: CEF-Drop: Packet from 133.69.24.0 (Te4/1.42) to 57.128.16.0, Verify Unicast Reverse-Path feature Sep 8 10:49:59.422 CEST: CEF-Drop: Packet from 114.46.39.0 (Te4/1.42) to 192.4.227.0, Verify Unicast Reverse-Path feature Sep 8 10:49:59.622 CEST: CEF-Drop: Packet from 135.96.1.0 (Te4/1.42) to 2.151.158.0, Verify Unicast Reverse-Path feature Sep 8 10:49:59.822 CEST: CEF-Drop: Packet from 162.16.59.0 (Te4/1.42) to 205.67.228.0, Verify Unicast Reverse-Path feature .... HOXBOX#sh int ten4/1 TenGigabitEthernet4/1 is up, line protocol is up (connected) Hardware is C6k 10000Mb 802.3, address is 0011.bb33.2600 (bia 0011.bb33.2600) MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec, reliability 255/255, txload 1/255, rxload 194/255 Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set Keepalive set (10 sec) Full-duplex, 10Gb/s input flow-control is off, output flow-control is off ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:05:00, output 00:00:37, output hang never Last clearing of "show interface" counters 00:05:26 Input queue: 0/4096/12860846/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 30 second input rate 7618968000 bits/sec, 14880795 packets/sec 30 second output rate 0 bits/sec, 0 packets/sec L2 Switched: ucast: 0 pkt, 0 bytes - mcast: 2 pkt, 180 bytes L3 in Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes mcast L3 out Switched: ucast: 0 pkt, 0 bytes mcast: 0 pkt, 0 bytes 4538227508 packets input, 290446560820 bytes, 0 no buffer Received 2 broadcasts (0 IP multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 6430423 overrun, 0 ignored 0 watchdog, 0 multicast, 0 pause input 0 input packets with dribble condition detected 5 packets output, 2130 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 PAUSE output 0 output buffer failures, 0 output buffers swapped out HOXBOX#show processes cpu | i ^CPU CPU utilization for five seconds: 9%/0%; one minute: 3%; five minutes: 6% SRC: rand(43.0.0.0 .. 220.255.255.255) DST: rand(1.0.0.0 .. 220.255.255.255) It's entirely possible, and rather easy, to get interrupt load to 100% in PFC3. One easy way to do it, is to send L2 broadcast to valid L3 IP unicast. And others. Most likely you just generated packets that were punted to software, perhaps you may have been able to secure them with mls rate-limit or CoPP, but there are DoS vectors you can't protect PFC3 from. -- ++ytti From randy at psg.com Mon Sep 8 05:08:43 2008 From: randy at psg.com (Randy Bush) Date: Mon, 08 Sep 2008 19:08:43 +0900 Subject: an effect of ignoring BCP38 In-Reply-To: <20080908054030.GA16241@vacation.karoshi.com.> References: <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> <3861BD57-759F-4EE5-A274-DBCDE7F7485B@ianai.net> <20080905052227.GA8309@vacation.karoshi.com.> <48C3862D.6020200@psg.com> <20080908054030.GA16241@vacation.karoshi.com.> Message-ID: <48C4F9AB.60200@psg.com> bmanning at vacation.karoshi.com wrote: > On Sun, Sep 07, 2008 at 07:43:41PM +1200, Randy Bush wrote: >>> http://www.caida.org/workshops/wide/0808/slides/measuring_reverse_paths.pdf >> great work on a tough problem > yes, but would it work if we all did BCP38 filtering? i think kc said it all well enough From wyystar at gmail.com Mon Sep 8 08:20:38 2008 From: wyystar at gmail.com (yangyang. wang) Date: Mon, 8 Sep 2008 21:20:38 +0800 Subject: why not AS number based prefixes aggregation Message-ID: <10fbbf5a0809080620t63cfac5fh1f62e7c2926e39d9@mail.gmail.com> Hi, everyone: For routing scalability issues, I have a question: why not deploy AS number based routing scheme? BGP is path vector protocol and the shortest paths are calculated based on traversed AS numbers. The prefixes in the same AS almost have the same AS_PATH associated, and aggregating prefixes according to AS will shrink BGP routing table significantly. I don't know what comments the ISPs make on this kind of routing scheme. -yang From nanog at daork.net Mon Sep 8 08:36:36 2008 From: nanog at daork.net (Nathan Ward) Date: Tue, 9 Sep 2008 01:36:36 +1200 Subject: why not AS number based prefixes aggregation In-Reply-To: <10fbbf5a0809080620t63cfac5fh1f62e7c2926e39d9@mail.gmail.com> References: <10fbbf5a0809080620t63cfac5fh1f62e7c2926e39d9@mail.gmail.com> Message-ID: On 9/09/2008, at 1:20 AM, yangyang. wang wrote: > Hi, everyone: > > For routing scalability issues, I have a question: why not > deploy AS > number based routing scheme? BGP is path vector protocol and the > shortest > paths are calculated based on traversed AS numbers. The prefixes in > the same > AS almost have the same AS_PATH associated, and aggregating prefixes > according to AS will shrink BGP routing table significantly. I don't > know > what comments the ISPs make on this kind of routing scheme. I expect you'll see something similar to this in IPv6 long term - most ASes will likely not need to originate more than their RIR 'block' (I can never figure out whether to call it an assignment or an allocation, and whenever I do I seem to get it wrong). Note that many ASes are expected to intentionally de-aggregate their prefixes. We've so far expected to see this for traffic engineering purposes (ie. to control sharing of load across several different links), however we might see intentional de-aggregation by people attempting to minimise BGP prefix hijacking? Who knows. That's a pretty scary though when considering IPv6.. There was a Cisco slide somewhere (I think originally by Tony Hain?) that had info about that, ie. actual numbers. It's slide 24 (and several slides leading up to it) in the following slide pack by Vince Fuller, but it was old in Feb 2007 when this was put together, so it's even older now - anyone have anything more recent. Anyway, enjoy: http://www.apricot2016.info/apricot2007/presentation/apia-future-routing/apia-future-routing-vince-fuller.pdf -- Nathan Ward From swb at employees.org Mon Sep 8 08:46:27 2008 From: swb at employees.org (Scott Brim) Date: Mon, 8 Sep 2008 09:46:27 -0400 Subject: why not AS number based prefixes aggregation In-Reply-To: <10fbbf5a0809080620t63cfac5fh1f62e7c2926e39d9@mail.gmail.com> References: <10fbbf5a0809080620t63cfac5fh1f62e7c2926e39d9@mail.gmail.com> Message-ID: <20080908134627.GA4108@cisco.com> Excerpts from yangyang. wang on Mon, Sep 08, 2008 09:20:38PM +0800: > Hi, everyone: > > For routing scalability issues, I have a question: why not deploy AS > number based routing scheme? BGP is path vector protocol and the shortest > paths are calculated based on traversed AS numbers. The prefixes in the same > AS almost have the same AS_PATH associated, and aggregating prefixes > according to AS will shrink BGP routing table significantly. I don't know > what comments the ISPs make on this kind of routing scheme. > > > -yang It might be the right level of granularity for policy but is too coarse for routing. You want to be able to route on prefixes (even if not everyone does it) for flexibility/TE. Also, ASNs are not aggregatable so we can't use them to represent a large number of independently routed networks. From swb at employees.org Mon Sep 8 08:46:27 2008 From: swb at employees.org (Scott Brim) Date: Mon, 8 Sep 2008 09:46:27 -0400 Subject: why not AS number based prefixes aggregation In-Reply-To: <10fbbf5a0809080620t63cfac5fh1f62e7c2926e39d9@mail.gmail.com> References: <10fbbf5a0809080620t63cfac5fh1f62e7c2926e39d9@mail.gmail.com> Message-ID: <20080908134627.GA4108@cisco.com> Excerpts from yangyang. wang on Mon, Sep 08, 2008 09:20:38PM +0800: > Hi, everyone: > > For routing scalability issues, I have a question: why not deploy AS > number based routing scheme? BGP is path vector protocol and the shortest > paths are calculated based on traversed AS numbers. The prefixes in the same > AS almost have the same AS_PATH associated, and aggregating prefixes > according to AS will shrink BGP routing table significantly. I don't know > what comments the ISPs make on this kind of routing scheme. > > > -yang It might be the right level of granularity for policy but is too coarse for routing. You want to be able to route on prefixes (even if not everyone does it) for flexibility/TE. Also, ASNs are not aggregatable so we can't use them to represent a large number of independently routed networks. From vixie at isc.org Mon Sep 8 09:07:02 2008 From: vixie at isc.org (Paul Vixie) Date: Mon, 08 Sep 2008 14:07:02 +0000 Subject: an effect of ignoring BCP38 In-Reply-To: <48C4F9AB.60200@psg.com> (Randy Bush's message of "Mon\, 08 Sep 2008 19\:08\:43 +0900") References: <20080908054030.GA16241@vacation.karoshi.com.> <48C4F9AB.60200@psg.com> Message-ID: bmanning at vacation.karoshi.com wrote: > yes, but would it work if we all did BCP38 filtering? randy at psg.com (Randy Bush) writes: > i think kc said it all well enough i'd be satisfied if bcp38 were widely enough deployed so that experiments based on ip spoofing wouldn't be scientifically valid due to sample size and population size issues. i know there's no way to force or enforce, nor any way to prove, universal bcp38 compliance, and so i know that all apps, protocols, firewalls, and ops staff will have to live with ip spoofing as a real possibility forever. in spite of that i would like ip spoofing to become an unreliable service. -- Paul Vixie From herrin-nanog at dirtside.com Mon Sep 8 09:35:14 2008 From: herrin-nanog at dirtside.com (William Herrin) Date: Mon, 8 Sep 2008 10:35:14 -0400 Subject: why not AS number based prefixes aggregation In-Reply-To: <10fbbf5a0809080620t63cfac5fh1f62e7c2926e39d9@mail.gmail.com> References: <10fbbf5a0809080620t63cfac5fh1f62e7c2926e39d9@mail.gmail.com> Message-ID: <3c3e3fca0809080735m7f292201u12b487428819b5b1@mail.gmail.com> On Mon, Sep 8, 2008 at 9:20 AM, yangyang. wang wrote: > For routing scalability issues, I have a question: why not deploy AS > number based routing scheme? BGP is path vector protocol and the shortest > paths are calculated based on traversed AS numbers. The prefixes in the same > AS almost have the same AS_PATH associated, and aggregating prefixes > according to AS will shrink BGP routing table significantly. I don't know > what comments the ISPs make on this kind of routing scheme. Yang, Two reasons: 1. The AS# alone is insufficiently granular to support traffic engineering for inbound traffic. 2. It would overload a location function on the existing identity function. The AS# presently identifies the entity announcing the routes. Routes from the same AS# come from the same entity. If we routed by AS#, the AS# would also serve to specify the entity's location in the network graph. One of the implications of the research in the RRG is that this identity + location functional overloading is the root cause of our route table problems. Specifically, the IP address both provides a node identity for use by the layer-4 protocols and a layer-3 location within the network graph. Had the IP protocol separated the two functions, it would be almost as trivial to expand the routing system as it is to expand the DNS system because the location part effectively aggregates by topology while the identity part has a nasty habit of changing locations. Unfortunately that realization doesn't appear to have left any corrective actions which are both clean and compatible with the existing system. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From morrowc.lists at gmail.com Mon Sep 8 10:30:40 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 8 Sep 2008 11:30:40 -0400 Subject: why not AS number based prefixes aggregation In-Reply-To: <10fbbf5a0809080620t63cfac5fh1f62e7c2926e39d9@mail.gmail.com> References: <10fbbf5a0809080620t63cfac5fh1f62e7c2926e39d9@mail.gmail.com> Message-ID: <75cb24520809080830v212f3761g3807aa95fcf1144b@mail.gmail.com> On Mon, Sep 8, 2008 at 9:20 AM, yangyang. wang wrote: > Hi, everyone: > > For routing scalability issues, I have a question: why not deploy AS > number based routing scheme? BGP is path vector protocol and the shortest > paths are calculated based on traversed AS numbers. The prefixes in the same > AS almost have the same AS_PATH associated, and aggregating prefixes > according to AS will shrink BGP routing table significantly. I don't know > what comments the ISPs make on this kind of routing scheme. you might look at LISP, which is sort of like 'route by asn', with some other benefits added as well. -Chris From andrews at ltinet.net Mon Sep 8 10:33:27 2008 From: andrews at ltinet.net (Andrew Staples) Date: Mon, 8 Sep 2008 23:33:27 +0800 Subject: NTT/ChinaTelCom troubleshooting In-Reply-To: <006D6E61F6B537498FBEB95E80A26E1E019F0507CD@NLI-CCR-SVR.nlightphotonics.com> References: <006D6E61F6B537498FBEB95E80A26E1E019F0507CD@NLI-CCR-SVR.nlightphotonics.com> Message-ID: <000301c911c8$3f1ee310$bd5ca930$@net> Our connectivity from the US to ChinaTelCom has been in the toilet for 2 months. The Olympics are over, and I'm assured by my Shanghai contacts that The Great Firewall of China has been relaxed, yet the problem remains. Local loops on each end test fine to other localized ip space. Symptoms include large-email delivery delays/failures, large file transfer failures. Firewalls and VPNs have been reviewed, NOCS have been contacted. Fingerpointing is raging at its finest. US endpoint is AS7358 Transit is AS2914 CN endpoint is AS4134 If there is anyone from those three networks who can help us figure out why large packets are dropping on transmits from the US to CN, I would really appreciate an off-list reply. Heck, I'll take any replies from anyone that might have some inside information or similar experiences, or give me some ideas on the best way to do some external black-hole router/mtu munging detective work on these networks. Thanks, Andrew From jeroen at unfix.org Mon Sep 8 10:36:39 2008 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 08 Sep 2008 17:36:39 +0200 Subject: why not AS number based prefixes aggregation In-Reply-To: <75cb24520809080830v212f3761g3807aa95fcf1144b@mail.gmail.com> References: <10fbbf5a0809080620t63cfac5fh1f62e7c2926e39d9@mail.gmail.com> <75cb24520809080830v212f3761g3807aa95fcf1144b@mail.gmail.com> Message-ID: <48C54687.2080003@spaghetti.zurich.ibm.com> Christopher Morrow wrote: > On Mon, Sep 8, 2008 at 9:20 AM, yangyang. wang wrote: >> Hi, everyone: >> >> For routing scalability issues, I have a question: why not deploy AS >> number based routing scheme? BGP is path vector protocol and the shortest >> paths are calculated based on traversed AS numbers. The prefixes in the same >> AS almost have the same AS_PATH associated, and aggregating prefixes >> according to AS will shrink BGP routing table significantly. I don't know >> what comments the ISPs make on this kind of routing scheme. > > you might look at LISP, which is sort of like 'route by asn', with > some other benefits added as well. > > NANOG site changed, thus that is now: http://www.nanog.org/meetings/nanog40/presentations/lightning-farinacci.pdf and: http://www.nanog.org/meetings/nanog41/presentations/lisp-nanog-abq.pdf Also check http://www.lisp4.net/ as they are actually testing this in live environments :) 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 Valdis.Kletnieks at vt.edu Mon Sep 8 10:47:53 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 08 Sep 2008 11:47:53 -0400 Subject: an effect of ignoring BCP38 In-Reply-To: Your message of "Sat, 06 Sep 2008 06:49:05 PDT." <20080906134905.GA75970@rommie.caida.org> References: <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> <3861BD57-759F-4EE5-A274-DBCDE7F7485B@ianai.net> <20080905052227.GA8309@vacation.karoshi.com> <20080906134905.GA75970@rommie.caida.org> Message-ID: <22854.1220888873@turing-police.cc.vt.edu> On Sat, 06 Sep 2008 06:49:05 PDT, k claffy said: > > do that many networks really allow spoofing? i used > to think so, based on hearsay, but rob beverly's > http://spoofer.csail.mit.edu/summary.php suggests > things are a lot better than they used to be, arbor's > last survey echos same. are rob's numbers inconsistent > with numbers anyone else believes to be true? You can easily have a network configuration where 95% of the networks do very stringent BCP38 on their customer-facing connections, but the spoofing sources are carefully chosen to be within the 5% of places that aren't filtering... Plus, there's nothing that says that a network can't do BCP38 on 99.998% of its ports, but has a punchout for the 3 or 4 ports that need it for network monitoring/research. So a network could be reported as "non-spoofable" to the MIT project, *and* still provide a sensor machine for the reverse path project... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From owen at delong.com Mon Sep 8 10:58:15 2008 From: owen at delong.com (Owen DeLong) Date: Mon, 8 Sep 2008 08:58:15 -0700 Subject: why not AS number based prefixes aggregation In-Reply-To: <20080908134627.GA4108@cisco.com> References: <10fbbf5a0809080620t63cfac5fh1f62e7c2926e39d9@mail.gmail.com> <20080908134627.GA4108@cisco.com> Message-ID: On Sep 8, 2008, at 6:46 AM, Scott Brim wrote: > Excerpts from yangyang. wang on Mon, Sep 08, 2008 09:20:38PM +0800: >> Hi, everyone: >> >> For routing scalability issues, I have a question: why not >> deploy AS >> number based routing scheme? BGP is path vector protocol and the >> shortest >> paths are calculated based on traversed AS numbers. The prefixes in >> the same >> AS almost have the same AS_PATH associated, and aggregating prefixes >> according to AS will shrink BGP routing table significantly. I >> don't know >> what comments the ISPs make on this kind of routing scheme. >> >> >> -yang > > It might be the right level of granularity for policy but is too > coarse for routing. You want to be able to route on prefixes (even if > not everyone does it) for flexibility/TE. Also, ASNs are not > aggregatable so we can't use them to represent a large number of > independently routed networks. An AS is a collection of networks with a common routing policy. If you are subdividing into multiple routing policies for TE purposes, you, theoretically, need separate ASNs for each routing policy. BTW, if you have multiple unique routing policies, it is perfectly valid to justify multiple ASNs on that basis. Owen From wyystar at gmail.com Mon Sep 8 11:04:24 2008 From: wyystar at gmail.com (yangyang. wang) Date: Tue, 9 Sep 2008 00:04:24 +0800 Subject: why not AS number based prefixes aggregation In-Reply-To: <20080908134627.GA4108@cisco.com> References: <10fbbf5a0809080620t63cfac5fh1f62e7c2926e39d9@mail.gmail.com> <20080908134627.GA4108@cisco.com> Message-ID: <10fbbf5a0809080904s4d8f37f4j6e677b6c4e03d6b@mail.gmail.com> Thank you, Scott. TE is a key reason for using specific prefixes. I think that most TEs are deployed in intra-domain, and the inter-domain TEs applied to downstream AS multihomed to many different upstream ASes could be made thru AS number based aggregation. The TE between two ASes with many links (for load balance) may be implemented by layer-2 filter list staticly configured. 2008/9/8 Scott Brim > Excerpts from yangyang. wang on Mon, Sep 08, 2008 09:20:38PM +0800: > > Hi, everyone: > > > > For routing scalability issues, I have a question: why not deploy AS > > number based routing scheme? BGP is path vector protocol and the > shortest > > paths are calculated based on traversed AS numbers. The prefixes in the > same > > AS almost have the same AS_PATH associated, and aggregating prefixes > > according to AS will shrink BGP routing table significantly. I don't know > > what comments the ISPs make on this kind of routing scheme. > > > > > > -yang > > It might be the right level of granularity for policy but is too > coarse for routing. You want to be able to route on prefixes (even if > not everyone does it) for flexibility/TE. Also, ASNs are not > aggregatable so we can't use them to represent a large number of > independently routed networks. > > From wyystar at gmail.com Mon Sep 8 11:04:24 2008 From: wyystar at gmail.com (yangyang. wang) Date: Tue, 9 Sep 2008 00:04:24 +0800 Subject: why not AS number based prefixes aggregation In-Reply-To: <20080908134627.GA4108@cisco.com> References: <10fbbf5a0809080620t63cfac5fh1f62e7c2926e39d9@mail.gmail.com> <20080908134627.GA4108@cisco.com> Message-ID: <10fbbf5a0809080904s4d8f37f4j6e677b6c4e03d6b@mail.gmail.com> Thank you, Scott. TE is a key reason for using specific prefixes. I think that most TEs are deployed in intra-domain, and the inter-domain TEs applied to downstream AS multihomed to many different upstream ASes could be made thru AS number based aggregation. The TE between two ASes with many links (for load balance) may be implemented by layer-2 filter list staticly configured. 2008/9/8 Scott Brim > Excerpts from yangyang. wang on Mon, Sep 08, 2008 09:20:38PM +0800: > > Hi, everyone: > > > > For routing scalability issues, I have a question: why not deploy AS > > number based routing scheme? BGP is path vector protocol and the > shortest > > paths are calculated based on traversed AS numbers. The prefixes in the > same > > AS almost have the same AS_PATH associated, and aggregating prefixes > > according to AS will shrink BGP routing table significantly. I don't know > > what comments the ISPs make on this kind of routing scheme. > > > > > > -yang > > It might be the right level of granularity for policy but is too > coarse for routing. You want to be able to route on prefixes (even if > not everyone does it) for flexibility/TE. Also, ASNs are not > aggregatable so we can't use them to represent a large number of > independently routed networks. > > From davei at otd.com Mon Sep 8 11:20:58 2008 From: davei at otd.com (Dave Israel) Date: Mon, 08 Sep 2008 12:20:58 -0400 Subject: why not AS number based prefixes aggregation In-Reply-To: <10fbbf5a0809080904s4d8f37f4j6e677b6c4e03d6b@mail.gmail.com> References: <10fbbf5a0809080620t63cfac5fh1f62e7c2926e39d9@mail.gmail.com> <20080908134627.GA4108@cisco.com> <10fbbf5a0809080904s4d8f37f4j6e677b6c4e03d6b@mail.gmail.com> Message-ID: <48C550EA.80403@otd.com> If I understand you right, what you're suggesting is that, in place of a MED or a localpref, I deploy a layer 2 filter on all of my devices for every prefix I want to touch the policy for at a level more granular than AS. This does not improve the scalability of BGP, it destroys that scalability and merely trades hardware capacity used for routing updates for capacity used for manual filters. At any rate, you cannot aggregate somebody else's announcements. Doing so destroys policy information (like more specific announcements, MEDs, and communities) and creates implementation nightmares (like handling route withdrawls.) yangyang. wang wrote: > Thank you, Scott. > TE is a key reason for using specific prefixes. I think that most TEs are > deployed in intra-domain, and the inter-domain TEs applied to downstream AS > multihomed to many different upstream ASes could be made thru AS number > based aggregation. The TE between two ASes with many links (for load > balance) may be implemented by layer-2 filter list staticly configured. > > 2008/9/8 Scott Brim > > >> Excerpts from yangyang. wang on Mon, Sep 08, 2008 09:20:38PM +0800: >> >>> Hi, everyone: >>> >>> For routing scalability issues, I have a question: why not deploy AS >>> number based routing scheme? BGP is path vector protocol and the >>> >> shortest >> >>> paths are calculated based on traversed AS numbers. The prefixes in the >>> >> same >> >>> AS almost have the same AS_PATH associated, and aggregating prefixes >>> according to AS will shrink BGP routing table significantly. I don't know >>> what comments the ISPs make on this kind of routing scheme. >>> >>> >>> -yang >>> >> It might be the right level of granularity for policy but is too >> coarse for routing. You want to be able to route on prefixes (even if >> not everyone does it) for flexibility/TE. Also, ASNs are not >> aggregatable so we can't use them to represent a large number of >> independently routed networks. >> >> >> From ge at linuxbox.org Mon Sep 8 11:32:15 2008 From: ge at linuxbox.org (Gadi Evron) Date: Mon, 8 Sep 2008 11:32:15 -0500 (CDT) Subject: Bandcon (apparently?) no longer providing service to Atrivo / Intercage Message-ID: Update, Monday, Sept 8, 12:00 p.m. ET: Todd Braning, vice president of BandCon, just e-mailed me to say that BandCon also has stopped providing connectivity to Atrivo/Intercage. From his e-mail: "Intercage, a new customer, was connected to the BandCon Network for total of about a week. Oncewe recognized and issue with Intercage, BandCon took immediate action and terminated services. We are no longer providing services to AS27595. This can be confirmed here." http://www.cidr-report.org/cgi-bin/as-report?as=27595&view=2.0 >From the Washington Post article again. Added "apparently" in the subject line to avoid BGP surprises again. WV FIBER is cutting them off on Thursday. I am starting a pool to see which of their ready-made ASs they will move to. Gadi. From rveloso at cs.ucla.edu Mon Sep 8 12:10:58 2008 From: rveloso at cs.ucla.edu (Ricardo Oliveira) Date: Mon, 8 Sep 2008 10:10:58 -0700 Subject: why not AS number based prefixes aggregation In-Reply-To: <10fbbf5a0809080620t63cfac5fh1f62e7c2926e39d9@mail.gmail.com> References: <10fbbf5a0809080620t63cfac5fh1f62e7c2926e39d9@mail.gmail.com> Message-ID: <0F2D417A-DCB8-4232-9A2D-A6EFF27CE4B5@cs.ucla.edu> Topological aggregation based on ASN is often too course granularity, see this paper: http://www.cs.ucla.edu/~rveloso/papers/giro.pdf specifically Fig4 is a good example, and sec 4C. Cheers, --Ricardo On Sep 8, 2008, at 6:20 AM, yangyang. wang wrote: > Hi, everyone: > > For routing scalability issues, I have a question: why not > deploy AS > number based routing scheme? BGP is path vector protocol and the > shortest > paths are calculated based on traversed AS numbers. The prefixes in > the same > AS almost have the same AS_PATH associated, and aggregating prefixes > according to AS will shrink BGP routing table significantly. I > don't know > what comments the ISPs make on this kind of routing scheme. > > > -yang From ge at linuxbox.org Mon Sep 8 12:34:05 2008 From: ge at linuxbox.org (Gadi Evron) Date: Mon, 8 Sep 2008 12:34:05 -0500 (CDT) Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: <12A7243745004CF880DEA8DDC5D7BFC5@NOCMOBILE> References: <12A7243745004CF880DEA8DDC5D7BFC5@NOCMOBILE> Message-ID: On Sun, 7 Sep 2008, InterCage - Russ wrote: > Hello Everyone, > > Good morning. > Seeing the activity in regards to our company here at NANOG, I believe this is the most reasonable and responsible place to respond to the current issues on our network. We hope to obtain non-bias opinion's and good honest and truthful information from the users here. > > Being that there are much larger operators here then us, what kind of insight can you give to the issues that have arisen? > > We've near completely removed (completion monday 09/08/08) Hostfresh from our network. 2 of their /24's have been removed: > 58.65.238.0/24 dropped > 58.65.239.0/24 dropped > The machine's they leased from us have been canceled. Thank you Russ. That is a great step in the right direction dropping this one client. It is appreciated, although it's just one bad apple on a big tree. However, I don't want to pick on you, so let's reframe the subject: > What do you suggest for the next move? Well, perhaps you can share any information with us on a legitimate client you have? > Thank you for your time. Have a great day. > > --- > Russell M. > InterCage, Inc. > From surfer at mauigateway.com Mon Sep 8 12:59:29 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 8 Sep 2008 10:59:29 -0700 Subject: InterCage, Inc. (NOT Atrivo) Message-ID: <20080908105929.256D8241@resin13.mta.everyone.net> --- ge at linuxbox.org wrote: Well, perhaps you can share any information with us on a legitimate client you have? ---------------------------------- Now why do you have to go there? Just to fan the flames for fun and profit? :-( scott From ge at linuxbox.org Mon Sep 8 13:04:26 2008 From: ge at linuxbox.org (Gadi Evron) Date: Mon, 8 Sep 2008 13:04:26 -0500 (CDT) Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: <20080908105929.256D8241@resin13.mta.everyone.net> References: <20080908105929.256D8241@resin13.mta.everyone.net> Message-ID: On Mon, 8 Sep 2008, Scott Weeks wrote: > > > --- ge at linuxbox.org wrote: > > Well, perhaps you can share any information with us on a legitimate client > you have? > ---------------------------------- > > > Now why do you have to go there? Just to fan the flames for fun and profit? :-( I haven't seen any flames, I've seen them claim they cleaned up, instead of pointing out all their other bad clients, I am asking for a good one. Should be easy enough to manufacture. I am interesting in you take on this: I am starting to think of the horror of whoever gets assigned these IP addresses next trying to clean them all up so they are usable again. They are listed *everywhere* for a long time now. Gadi. > scott > From surfer at mauigateway.com Mon Sep 8 13:09:09 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 8 Sep 2008 11:09:09 -0700 Subject: InterCage, Inc. (NOT Atrivo) Message-ID: <20080908110909.256D9F75@resin13.mta.everyone.net> --- ge at linuxbox.org wrote: On Mon, 8 Sep 2008, Scott Weeks wrote: > > --- ge at linuxbox.org wrote: > > Well, perhaps you can share any information with us on a legitimate client > you have? > ---------------------------------- > > Now why do you have to go there? Just to fan the flames for fun and profit? :-( I haven't seen any flames, I've seen them claim they cleaned up, instead of pointing out all their other bad clients, I am asking for a good one. Should be easy enough to manufacture. ------------------------------------- Stop. Please. scott From jpleger at gmail.com Mon Sep 8 13:10:11 2008 From: jpleger at gmail.com (James Pleger) Date: Mon, 8 Sep 2008 11:10:11 -0700 Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: <20080908105929.256D8241@resin13.mta.everyone.net> References: <20080908105929.256D8241@resin13.mta.everyone.net> Message-ID: <221481660809081110g4c9fe18eg60c4921b14bb39d3@mail.gmail.com> On Mon, Sep 8, 2008 at 10:59 AM, Scott Weeks wrote: > > > --- ge at linuxbox.org wrote: > > Well, perhaps you can share any information with us on a legitimate client > you have? > ---------------------------------- > > > Now why do you have to go there? Just to fan the flames for fun and profit? :-( > > scott Scott, I am unsure how it is fun or profitable to ask this question which has been on everyones mind. I haven't personally seen anything worth noting that wasn't malicious from Intercage or Hostfresh. I can tell you the only thing that was even remotely legitimate from a report of all Hostfresh/Intercage traffic from my network was a couple porn sites. Everything else was malicious communication. I am sure if I looked into it more I could find some exploits related to the sites. Thanks, James > > From ge at linuxbox.org Mon Sep 8 13:13:55 2008 From: ge at linuxbox.org (Gadi Evron) Date: Mon, 8 Sep 2008 13:13:55 -0500 (CDT) Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: <20080908110909.256D9F75@resin13.mta.everyone.net> References: <20080908110909.256D9F75@resin13.mta.everyone.net> Message-ID: On Mon, 8 Sep 2008, Scott Weeks wrote: > > > --- ge at linuxbox.org wrote: > On Mon, 8 Sep 2008, Scott Weeks wrote: >> >> --- ge at linuxbox.org wrote: >> >> Well, perhaps you can share any information with us on a legitimate client >> you have? >> ---------------------------------- >> >> Now why do you have to go there? Just to fan the flames for fun and profit? :-( > > > I haven't seen any flames, I've seen them claim they cleaned up, instead > of pointing out all their other bad clients, I am asking for a good one. > Should be easy enough to manufacture. > ------------------------------------- > > Stop. Please. > Scott, second attempt to get a relavnt remark out of you flame-baiting: Do you feel future peers of Atrivo / Intercage should be making some sort of abuse due dilligence? How does such a process get done? Relying on black lists doesn't seem too reliable as a solution. Obviously host lost some money now after buying a provider with a big client that was just depeered, so it is now a financial concern. Gadi. > scott > From surfer at mauigateway.com Mon Sep 8 13:20:49 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 8 Sep 2008 11:20:49 -0700 Subject: InterCage, Inc. (NOT Atrivo) Message-ID: <20080908112049.256D9BBE@resin13.mta.everyone.net> --- jpleger at gmail.com wrote: I am sure if I looked into it more I could find some exploits related to the sites. ------------------------------------- "Why software piracy might actually be good for companies." Folks should clean their own house before pointing fingers at others... scott From mpetach at netflight.com Mon Sep 8 13:25:10 2008 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 8 Sep 2008 11:25:10 -0700 Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: References: <12A7243745004CF880DEA8DDC5D7BFC5@NOCMOBILE> Message-ID: <63ac96a50809081125u5d053021i5df7e822084283c7@mail.gmail.com> On 9/8/08, Gadi Evron wrote: > On Sun, 7 Sep 2008, InterCage - Russ wrote: > Thank you Russ. That is a great step in the right direction dropping this > one client. It is appreciated, although it's just one bad apple on a big > tree. > > However, I don't want to pick on you, so let's reframe the subject: > > > What do you suggest for the next move? > > > > Well, perhaps you can share any information with us on a legitimate client > you have? I do not think it is appropriate for ISPs to have to prove or demonstrate the legitimacy of their customer base. As a legitimate customer of an ISP, I would be *highly* incensed if my privacy were to be violated simply to provide "proof" that the ISP had legitimate clients. The notion of "innocent until proven guilty" I think is a much better model for us to work with. If you find clear miscreants, and have data to back it up, then a call for cleaning up the miscreants is somewhat acceptable, though I worry that we may descend into a witch hunt if this is taken too far to the extreme. However, a call to "prove your innocence" is entirely uncalled for, and opens ISPs up to being caught on the horns of a very nasty dillemma; either to maintain their customer's privacy, and be labelled as an evil, nasty, non-cooperative provider that must therefore be guilty, by their very dint of failure to prove their innocence; or, reveal their law-abiding, legitimate client information, and and then quickly lose those clients when they realize their records are no longer considered private at that ISP. If you have proof of clients engaging in illegal practices, then it is appropriate to go after those clients. But leave the legitimate clients alone. *putting down his pitchfork and torch, and walking away from the mob* Matt From ge at linuxbox.org Mon Sep 8 13:27:19 2008 From: ge at linuxbox.org (Gadi Evron) Date: Mon, 8 Sep 2008 13:27:19 -0500 (CDT) Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: <20080908112049.256D9BBE@resin13.mta.everyone.net> References: <20080908112049.256D9BBE@resin13.mta.everyone.net> Message-ID: On Mon, 8 Sep 2008, Scott Weeks wrote: > > > --- jpleger at gmail.com wrote: > I am sure if I looked into it more I could find some exploits related > to the sites. > ------------------------------------- > > > "Why software piracy might actually be good for companies." > > Folks should clean their own house before pointing fingers at others... My house may not be clean right now, but the cleaner is coming tomorrow. However, filth from their house is making my house smell. I am very happy they are willing to clean up, but it still smells for some reason. Enough with analogies, you are making this discussion into a hostile environment for them to reply in. What are you afraid of, anyway? Are you running a bullet-proof hosting farm? > scott > From surfer at mauigateway.com Mon Sep 8 13:28:16 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 8 Sep 2008 11:28:16 -0700 Subject: InterCage, Inc. (NOT Atrivo) Message-ID: <20080908112816.256D9504@resin13.mta.everyone.net> My apologies everyone, I shouldn't have said that. I'm done. scott --- surfer at mauigateway.com wrote: --- jpleger at gmail.com wrote: I am sure if I looked into it more I could find some exploits related to the sites. ------------------------------------- "Why software piracy might actually be good for companies." Folks should clean their own house before pointing fingers at others... -------------------------------------- From repstein at chello.at Mon Sep 8 13:29:21 2008 From: repstein at chello.at (Randy Epstein) Date: Mon, 8 Sep 2008 14:29:21 -0400 Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: References: <20080908110909.256D9F75@resin13.mta.everyone.net> Message-ID: <13E0EB188E134FE2A493B2596495E29B@D88CFA77634F40F> >Obviously host lost some money now after buying a provider with a big >client that was just depeered, so it is now a financial concern. > Gadi. On the floor .. dying here. From jpleger at gmail.com Mon Sep 8 13:30:49 2008 From: jpleger at gmail.com (James Pleger) Date: Mon, 8 Sep 2008 11:30:49 -0700 Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: <20080908112049.256D9BBE@resin13.mta.everyone.net> References: <20080908112049.256D9BBE@resin13.mta.everyone.net> Message-ID: <221481660809081130s4d1c9963r6cbb0490dd4f0246@mail.gmail.com> When I worked at an ISP I can say that my house was very clean. Takedowns were done in hours and we had a very large customer base. I will take on the clean house topic any time... I have done hundreds if not thousands of takedowns while I have worked at hosting companies, it isn't that hard to keep the house clean. However, what you have said in this topic has not been useful or brought anything that might be interesting to light at all. Please come back when you have something useful or productive to say. Thanks, James On Mon, Sep 8, 2008 at 11:20 AM, Scott Weeks wrote: > > > --- jpleger at gmail.com wrote: > I am sure if I looked into it more I could find some exploits related > to the sites. > ------------------------------------- > > > "Why software piracy might actually be good for companies." > > Folks should clean their own house before pointing fingers at others... > > scott > > From ge at linuxbox.org Mon Sep 8 13:31:39 2008 From: ge at linuxbox.org (Gadi Evron) Date: Mon, 8 Sep 2008 13:31:39 -0500 (CDT) Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: <13E0EB188E134FE2A493B2596495E29B@D88CFA77634F40F> References: <20080908110909.256D9F75@resin13.mta.everyone.net> <13E0EB188E134FE2A493B2596495E29B@D88CFA77634F40F> Message-ID: On Mon, 8 Sep 2008, Randy Epstein wrote: >> Obviously host lost some money now after buying a provider with a big >> client that was just depeered, so it is now a financial concern. > >> Gadi. > > On the floor .. dying here. :) :) From bambenek at gmail.com Mon Sep 8 13:44:25 2008 From: bambenek at gmail.com (John C. A. Bambenek) Date: Mon, 8 Sep 2008 13:44:25 -0500 Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: <63ac96a50809081125u5d053021i5df7e822084283c7@mail.gmail.com> References: <12A7243745004CF880DEA8DDC5D7BFC5@NOCMOBILE> <63ac96a50809081125u5d053021i5df7e822084283c7@mail.gmail.com> Message-ID: "> I do not think it is appropriate for ISPs to have to prove or demonstrate the > legitimacy of their customer base" Here is the exact point of contention and the point where I think people disagree. ISPs are the **first** line of defense against malware and badware. They are the ones closest to the customer and best able to "whack-a-mole". For those ISPs that do cater to a high proportion of bad actors, I quite rightly want them to demonstrate their legitimacy. By peering with them, there is a trust relationship formed... if there is a question that goes right to the heart of that trust, they ought to answer it, otherwise they ought to be de-peered as well. On Mon, Sep 8, 2008 at 1:25 PM, Matthew Petach wrote: > On 9/8/08, Gadi Evron wrote: >> On Sun, 7 Sep 2008, InterCage - Russ wrote: >> Thank you Russ. That is a great step in the right direction dropping this >> one client. It is appreciated, although it's just one bad apple on a big >> tree. >> >> However, I don't want to pick on you, so let's reframe the subject: >> >> > What do you suggest for the next move? >> > >> >> Well, perhaps you can share any information with us on a legitimate client >> you have? > > I do not think it is appropriate for ISPs to have to prove or demonstrate the > legitimacy of their customer base. As a legitimate customer of an ISP, I > would be *highly* incensed if my privacy were to be violated simply to > provide "proof" that the ISP had legitimate clients. > > The notion of "innocent until proven guilty" I think is a much better model for > us to work with. If you find clear miscreants, and have data to back it up, > then a call for cleaning up the miscreants is somewhat acceptable, though > I worry that we may descend into a witch hunt if this is taken too far to the > extreme. However, a call to "prove your innocence" is entirely uncalled for, > and opens ISPs up to being caught on the horns of a very nasty dillemma; > either to maintain their customer's privacy, and be labelled as an evil, nasty, > non-cooperative provider that must therefore be guilty, by their very dint of > failure to prove their innocence; or, reveal their law-abiding, > legitimate client > information, and and then quickly lose those clients when they realize their > records are no longer considered private at that ISP. > > If you have proof of clients engaging in illegal practices, then it is > appropriate > to go after those clients. But leave the legitimate clients alone. > > *putting down his pitchfork and torch, and walking away from the mob* > > Matt > > From ge at linuxbox.org Mon Sep 8 13:51:47 2008 From: ge at linuxbox.org (Gadi Evron) Date: Mon, 8 Sep 2008 13:51:47 -0500 (CDT) Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: <63ac96a50809081125u5d053021i5df7e822084283c7@mail.gmail.com> References: <12A7243745004CF880DEA8DDC5D7BFC5@NOCMOBILE> <63ac96a50809081125u5d053021i5df7e822084283c7@mail.gmail.com> Message-ID: On Mon, 8 Sep 2008, Matthew Petach wrote: > On 9/8/08, Gadi Evron wrote: >> On Sun, 7 Sep 2008, InterCage - Russ wrote: >> Thank you Russ. That is a great step in the right direction dropping this >> one client. It is appreciated, although it's just one bad apple on a big >> tree. >> >> However, I don't want to pick on you, so let's reframe the subject: >> >>> What do you suggest for the next move? >>> >> >> Well, perhaps you can share any information with us on a legitimate client >> you have? > > I do not think it is appropriate for ISPs to have to prove or demonstrate the > legitimacy of their customer base. As a legitimate customer of an ISP, I > would be *highly* incensed if my privacy were to be violated simply to > provide "proof" that the ISP had legitimate clients. What you say in this email makes a lot of sense. Thanks for pointing that out. Not being a lawyer, I think this also makes sense legally (as far as the Britain-like systems go). As to this particular case, I'd be satisfied if I see even just all the fake DNS traffic stop heading their way, anyway. Gadi. > The notion of "innocent until proven guilty" I think is a much better model for > us to work with. If you find clear miscreants, and have data to back it up, > then a call for cleaning up the miscreants is somewhat acceptable, though > I worry that we may descend into a witch hunt if this is taken too far to the > extreme. However, a call to "prove your innocence" is entirely uncalled for, > and opens ISPs up to being caught on the horns of a very nasty dillemma; > either to maintain their customer's privacy, and be labelled as an evil, nasty, > non-cooperative provider that must therefore be guilty, by their very dint of > failure to prove their innocence; or, reveal their law-abiding, > legitimate client > information, and and then quickly lose those clients when they realize their > records are no longer considered private at that ISP. > > If you have proof of clients engaging in illegal practices, then it is > appropriate > to go after those clients. But leave the legitimate clients alone. > > *putting down his pitchfork and torch, and walking away from the mob* > > Matt > From jra at baylink.com Mon Sep 8 13:55:29 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Mon, 8 Sep 2008 14:55:29 -0400 Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: <20080908110909.256D9F75@resin13.mta.everyone.net> References: <20080908110909.256D9F75@resin13.mta.everyone.net> Message-ID: <20080908185529.GG17955@cgi.jachomes.com> On Mon, Sep 08, 2008 at 11:09:09AM -0700, Scott Weeks wrote: > --- ge at linuxbox.org wrote: > On Mon, 8 Sep 2008, Scott Weeks wrote: > > > > --- ge at linuxbox.org wrote: > > > > Well, perhaps you can share any information with us on a legitimate client > > you have? > > ---------------------------------- > > > > Now why do you have to go there? Just to fan the flames for fun and profit? :-( > > > I haven't seen any flames, I've seen them claim they cleaned up, instead > of pointing out all their other bad clients, I am asking for a good one. > Should be easy enough to manufacture. > ------------------------------------- > > Stop. Please. No, Scott. You stop. "Do you *have any legitimate clients* at all, or should we all be turning our firehoses on *you* instead?" seems to be a perfectly valid question in a circumstance like this; are you asserting otherwise? Just because you don't like Gadi much does not mean that he doesn't ask cogent questions... occasionally. ;-) 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 Mon Sep 8 13:56:55 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Mon, 8 Sep 2008 14:56:55 -0400 Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: <221481660809081130s4d1c9963r6cbb0490dd4f0246@mail.gmail.com> References: <20080908112049.256D9BBE@resin13.mta.everyone.net> <221481660809081130s4d1c9963r6cbb0490dd4f0246@mail.gmail.com> Message-ID: <20080908185655.GH17955@cgi.jachomes.com> On Mon, Sep 08, 2008 at 11:30:49AM -0700, James Pleger wrote: > However, what you have said in this topic has not been useful or > brought anything that might be interesting to light at all. Please > come back when you have something useful or productive to say. And, again, yes he has. Absent any evidence that the hoster in question *has* lots of white customers as your employer does/did, then the question is still on the table, as far as I can see. 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 francis at cs.cornell.edu Mon Sep 8 14:31:18 2008 From: francis at cs.cornell.edu (Paul Francis) Date: Mon, 8 Sep 2008 15:31:18 -0400 Subject: why not AS number based prefixes aggregation In-Reply-To: <0F2D417A-DCB8-4232-9A2D-A6EFF27CE4B5@cs.ucla.edu> References: <10fbbf5a0809080620t63cfac5fh1f62e7c2926e39d9@mail.gmail.com> <0F2D417A-DCB8-4232-9A2D-A6EFF27CE4B5@cs.ucla.edu> Message-ID: <37BC8961A005144C8F5B8E4AD226DE1110E0DA@EXCHANGE2.cs.cornell.edu> This thread begs an interesting question: what is the right amount of granularity for load balance? Folks here are saying that one-entry-per-AS is too course...an AS wants to influence load on incoming links, and so it needs multiple entries. On the other hand, it is hard to imagine that we need hundreds of entries per AS, or even dozens. So I'm curious...if we could wave a magic wand and control the exact number of entries any AS needs to advertise, what would folks consider to be roughly the right number of entries? Thanks, PF > -----Original Message----- > From: Ricardo Oliveira [mailto:rveloso at cs.ucla.edu] > Sent: Monday, September 08, 2008 1:11 PM > To: nanog at merit.edu > Subject: Re: why not AS number based prefixes aggregation > > Topological aggregation based on ASN is often too course > granularity, see this paper: > http://www.cs.ucla.edu/~rveloso/papers/giro.pdf > specifically Fig4 is a good example, and sec 4C. > Cheers, > > --Ricardo > > On Sep 8, 2008, at 6:20 AM, yangyang. wang wrote: > > > Hi, everyone: > > > > For routing scalability issues, I have a question: why > not deploy > > AS number based routing scheme? BGP is path vector > protocol and the > > shortest paths are calculated based on traversed AS numbers. The > > prefixes in the same AS almost have the same AS_PATH > associated, and > > aggregating prefixes according to AS will shrink BGP routing table > > significantly. I don't know what comments the ISPs make on > this kind > > of routing scheme. > > > > > > -yang > > > From Benjamin.R.Boyd at windstream.com Mon Sep 8 14:49:34 2008 From: Benjamin.R.Boyd at windstream.com (Boyd, Benjamin R) Date: Mon, 8 Sep 2008 14:49:34 -0500 Subject: why not AS number based prefixes aggregation Message-ID: <3F045502966C304B963C72E3C442750E01B3B513@scarlitnt840.windstream.com> >-----Original Message----- >From: Paul Francis [mailto:francis at cs.cornell.edu] >Sent: Monday, September 08, 2008 2:31 PM >To: Ricardo Oliveira; nanog at merit.edu >Subject: RE: why not AS number based prefixes aggregation > > >This thread begs an interesting question: what is the right >amount of granularity for load balance? Folks here are saying >that one-entry-per-AS is too course...an AS wants to influence >load on incoming links, and so it needs multiple entries. > >On the other hand, it is hard to imagine that we need hundreds >of entries per AS, or even dozens. So I'm curious...if we >could wave a magic wand and control the exact number of >entries any AS needs to advertise, what would folks consider >to be roughly the right number of entries? > >Thanks, > >PF > Although hard to imagine, I would think that flexibility would be desired for those willing to implement/manage it. *************************************************************************************** The information contained in this message, including attachments, may contain privileged or confidential information that is intended to be delivered only to the person identified above. If you are not the intended recipient, or the person responsible for delivering this message to the intended recipient, Windstream requests that you immediately notify the sender and asks that you do not read the message or its attachments, and that you delete them without copying or sending them to anyone else. From bensons at riot.queuefull.net Mon Sep 8 14:56:55 2008 From: bensons at riot.queuefull.net (Benson Schliesser) Date: Mon, 8 Sep 2008 15:56:55 -0400 (EDT) Subject: why not AS number based prefixes aggregation In-Reply-To: <20080908134627.GA4108@cisco.com> References: <10fbbf5a0809080620t63cfac5fh1f62e7c2926e39d9@mail.gmail.com> <20080908134627.GA4108@cisco.com> Message-ID: <4167.209.145.182.26.1220903815.squirrel@riot.queuefull.net> On Mon, September 8, 2008 09:46, Scott Brim wrote: > Also, ASNs are not > aggregatable so we can't use them to represent a large number of > independently routed networks. Scott, I'm not sure an Autonomous System would want to be aggregated. By its nature it is capable of having arbitrary connectivity. On the other hand, addresses can be aggregated. An ASN-based address system would support a more efficient form of aggregation than we have today. And routing (including TE) could be supported by attributes, rather than by address/prefix-len. *shrug* Yang, As somebody pointed out already, LISP provides approximately the same sort of mechanism. Though it uses a list of Locators (backbone/core IP addresses) rather than ASNs to identify an Endpoint's site, relying on a lightweight form of tunneling through the core to support endpoint communication. This allows it to preserve both IPv4/v6 and existing global routing protocols (and thus deployed support). The downside is that it requires a more dynamic mapping mechanism than a theoretical ASN-based approach. You can learn more at http://www.lisp4.net/, and discuss it on the lisp-interest at lists.civil-tongue.net mailing list. Cheers, -Benson From jfmezei at vaxination.ca Mon Sep 8 21:21:24 2008 From: jfmezei at vaxination.ca (=?ISO-8859-1?Q?Jean-Fran=E7ois_Mezei?=) Date: Mon, 08 Sep 2008 22:21:24 -0400 Subject: why not AS number based prefixes aggregation In-Reply-To: <37BC8961A005144C8F5B8E4AD226DE1110E0DA@EXCHANGE2.cs.cornell.edu> References: <10fbbf5a0809080620t63cfac5fh1f62e7c2926e39d9@mail.gmail.com> <0F2D417A-DCB8-4232-9A2D-A6EFF27CE4B5@cs.ucla.edu> <37BC8961A005144C8F5B8E4AD226DE1110E0DA@EXCHANGE2.cs.cornell.edu> Message-ID: <48C5DDA4.30307@vaxination.ca> Paul Francis wrote: > AS, or even dozens. So I'm curious...if we could wave a magic wand and > control the exact number of entries any AS needs to advertise, what would > folks consider to be roughly the right number of entries? Wouldn't this greatly depend on the span/breath of your network ? If you are a large nationwide (or even international) ISP/network, then you want to be able to distribute your network so that someone on west coast trying to reach one of your west coast IP addresses will have a pretty direct route into your west coast infrastructure instead of funnelling all traffic into one central location. But a smaller ISP based in only one city would not need to distribute traffic through different entry points since traffic from each transit provider would end up on the same router. So I am not sure one could draw any "right number of entries". From cdl at asgaard.org Mon Sep 8 21:25:38 2008 From: cdl at asgaard.org (Christopher LILJENSTOLPE) Date: Mon, 8 Sep 2008 19:25:38 -0700 Subject: [Fwd:] Nvidia NICs with duplicate mac addresses In-Reply-To: <001f01c90f67$46e4d5e0$d4ae81a0$@berkman@reignmaker.net> References: <86skseu0hd.fsf@seastrom.com> <001f01c90f67$46e4d5e0$d4ae81a0$@berkman@reignmaker.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oh, it's the truth - trust me. There was an Interop show (back when it really was an Interoperability event) that was made quite enjoyable for the network staff by that set of NIC cards.... Chris On 05 Sep 2008, at 07.53, Scott Berkman wrote: > This reminds me of a story I was told a while back that there was a > batch > of 3com NIC's that all went out with the same MAC from the factory. I > never found out if that was a rumor/urban legend or the truth. Anyone > know firsthand or have an article about that? > > -Scott > > -----Original Message----- > From: Robert E. Seastrom [mailto:rs at seastrom.com] > Sent: Friday, September 05, 2008 10:33 AM > To: nanog at nanog.org > Subject: [Fwd:] Nvidia NICs with duplicate mac addresses > > > Forwarded to NANOG in the interests of wider awareness... having been > there and torn out my already scarce hair, duplicate MAC addresses can > really mess up your day... > > --- > > Just when you thought this couldn't happen any more... > > Copying from a different email list... > > mac address 04:4b:80:80:80:03, was showing up in multiple places > across the network. I googled the mac address and discovered that > other people are having the same issue with this mac address. Below > are some links describing the problem: > > http://forums.nvidia.com/index.php?showtopic=22148 > http://www.nvnews.net/vbulletin/archive/index.php/t-73469.html > > > I just wanted everyone to know about this problem in case you run > across similar slow "connectivity" issues. I believe the network card > is made by NVIDIA. > > > > - --- ??? Check my PGP key here: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xCB67593B -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJIxd6iAAoJEGmx2Mt/+Iw/TAUH/0zG2RUi2oJ3oNaPO0yNoz73 noV7ql2NVpJNtaJz8kmaeoZamE5pSVgJ1byj/wSknPimeAFdDUny+ZmPqSO8b0N4 E1Pqh9O5MegxVAZ2FjjTCLv9TvJ8mnH+l3pDPebqps43PGTyBfa6alZjceadMWDj NyPfS9yrne7JM6zaZt6mgBvfPc93ZXdaB77N4SteKRbplB+5FbzPzzE2HnEiY46E qxYbZHt9vT/6f9cyPZmH7AGjqnbNBaCMb/dXEWKn1LqkTWRUdhfbKTUUvvtUYvGJ tiT6EI4r8z/IlsCn9+APSA5mnsMDm8dI1/j48ogsgW/RumL2BBi9CEalJO4CHPo= =77sL -----END PGP SIGNATURE----- From hank at efes.iucc.ac.il Tue Sep 9 00:30:41 2008 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 9 Sep 2008 08:30:41 +0300 (IDT) Subject: Internet Traffic Growth Slows Message-ID: http://www.pcworld.com/article/150709/internet_growth_trends.html?tk=rss_news# -Hank From jra at baylink.com Tue Sep 9 11:08:51 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Tue, 9 Sep 2008 12:08:51 -0400 Subject: Status Page bookmarks? Message-ID: <20080909160851.GH23322@cgi.jachomes.com> I'm working with Virendra Rode on setting up a wiki for outages.org. One of the things we want to put there -- and yes, we know we'll likely be duplicating some work done elsewhere -- is as complete a list as possible of links to a) Network and Service status webpages and b) Web-based diagnostic tools. If y'all could take a minute, sometime today or tomorrow, to mine your bookmarks and reply -- off-list -- to this message with anything you've got to share, that'd be real cool. I'll be happy to do the first round of wikification. I haven't linked the page in to the public tree (such as it is) yet; I wanted to finish cleaning up the list we pulled over from puck. Cheers, -- jra -- Jay R. Ashworth jra at baylink.com Designer +-Internetworking------+---------+ RFC 2100 Ashworth & Associates | Best Practices Wiki | | '87 e24 St Petersburg FL USA +-http://bestpractices.wikia.com-+ +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me From francis at cs.cornell.edu Tue Sep 9 13:02:57 2008 From: francis at cs.cornell.edu (Paul Francis) Date: Tue, 9 Sep 2008 14:02:57 -0400 Subject: why not AS number based prefixes aggregation In-Reply-To: <48C5DDA4.30307@vaxination.ca> References: <10fbbf5a0809080620t63cfac5fh1f62e7c2926e39d9@mail.gmail.com> <0F2D417A-DCB8-4232-9A2D-A6EFF27CE4B5@cs.ucla.edu><37BC8961A005144C8F5B8E4AD226DE1110E0DA@EXCHANGE2.cs.cornell.edu> <48C5DDA4.30307@vaxination.ca> Message-ID: <37BC8961A005144C8F5B8E4AD226DE11144D9F@EXCHANGE2.cs.cornell.edu> Sorry, my question was not clear. By "entries" I meant "routes" or "prefixes". For instance, some ISPs today deaggregate in order to load-balance, so they advertise multiple prefixes or routes instead of one. Of course, the "right" number would vary from ISP to ISP (as someone already pointed out to me), but I'm not even sure what the criteria would be for how many routes one needs to load balance...i.e. depends on the number of AS neighbors?, depends on the number of depends on the number of BGP neighbors?, depends on your load balancing mechanism (MEDs versus path prepending versus ....???)? The point is this...BGP seems to give use two tools...a machete (AS numbers) and a scalpel (prefixes). If I want to cut a steak (load balance), the machete is too coarse, the scalpel is too fine. What's the right tool??? PF > -----Original Message----- > From: Jean-Fran?ois Mezei [mailto:jfmezei at vaxination.ca] > Sent: Monday, September 08, 2008 10:21 PM > To: nanog at nanog.org > Subject: Re: why not AS number based prefixes aggregation > > Paul Francis wrote: > > > AS, or even dozens. So I'm curious...if we could wave a magic wand > and > > control the exact number of entries any AS needs to advertise, what > would > > folks consider to be roughly the right number of entries? > > Wouldn't this greatly depend on the span/breath of your network ? If > you > are a large nationwide (or even international) ISP/network, then you > want to be able to distribute your network so that someone on west > coast > trying to reach one of your west coast IP addresses will have a pretty > direct route into your west coast infrastructure instead of funnelling > all traffic into one central location. > > But a smaller ISP based in only one city would not need to distribute > traffic through different entry points since traffic from each transit > provider would end up on the same router. > > So I am not sure one could draw any "right number of entries". > > From sdoyle at kddia.com Tue Sep 9 16:54:33 2008 From: sdoyle at kddia.com (Sean Doyle) Date: Tue, 09 Sep 2008 16:54:33 -0500 Subject: Comcast Email/Abuse Dept Contact Request Message-ID: <00b801c912c6$a51b1590$ef5140b0$@com> All, If there's anyone out there from Comcast's Email Administration or Abuse dept, can you please contact me off list? I've had a ticket open for over a week now and lets just say it's "being dealt with poorly". ;-) TIA, -- Sean Doyle Systems/Network Engineer KDDI America, Inc. - Chicago Office Direct: 630-227-1373 Main: 630-227-1350 Cell: 630-808-7207 Fax: 630-227-1360 NOTE: This electronic mail message may contain confidential and privileged information from KDDI America,Inc. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies. From ren.provo at gmail.com Tue Sep 9 16:57:22 2008 From: ren.provo at gmail.com (Ren Provo) Date: Tue, 9 Sep 2008 17:57:22 -0400 Subject: Comcast Email/Abuse Dept Contact Request In-Reply-To: <00b801c912c6$a51b1590$ef5140b0$@com> References: <00b801c912c6$a51b1590$ef5140b0$@com> Message-ID: <787581440809091457y296df29dl9d9b9f382c93bda4@mail.gmail.com> Hi Sean, I'll connect you with our team. There is a thread looking for assistance at your organization running for about that same amount of time. Bogon filters are fun. -ren On Tue, Sep 9, 2008 at 5:54 PM, Sean Doyle wrote: > All, > > > > If there's anyone out there from Comcast's Email Administration or Abuse > dept, can you please contact me off list? > > I've had a ticket open for over a week now and lets just say it's "being > dealt with poorly". ;-) > > > > TIA, > > -- > > Sean Doyle > > Systems/Network Engineer > > KDDI America, Inc. - Chicago Office > > Direct: 630-227-1373 Main: 630-227-1350 > > Cell: 630-808-7207 Fax: 630-227-1360 > > > > NOTE: This electronic mail message may contain confidential and privileged > information from KDDI America,Inc. If you are not the intended recipient, > any disclosure, photocopying, distribution or use of the contents of the > received information is prohibited. If you have received this e-mail in > error, please notify the sender immediately and permanently delete this > message and all related copies. > > > > From dhubbard at dino.hostasaurus.com Tue Sep 9 16:58:14 2008 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Tue, 9 Sep 2008 17:58:14 -0400 Subject: Comcast Email/Abuse Dept Contact Request Message-ID: From: Sean Doyle [mailto:sdoyle at kddia.com] > > All, > > If there's anyone out there from Comcast's Email > Administration or Abuse > dept, can you please contact me off list? > > I've had a ticket open for over a week now and lets just say > it's "being > dealt with poorly". ;-) > > Good luck with that. Dave From paul at blacknight.com Wed Sep 10 04:07:59 2008 From: paul at blacknight.com (Paul Kelly :: Blacknight) Date: Wed, 10 Sep 2008 10:07:59 +0100 Subject: Yahoo! mail admins? Message-ID: Hi There, Are there any Yahoo! e-mail admins on the list? We're having some issues at times delivering e-mail to yahoo.co.uk and sometimes some of the other yahoo networks. Thanks, 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 From chloekcy2000 at yahoo.ca Wed Sep 10 05:45:59 2008 From: chloekcy2000 at yahoo.ca (chloe K) Date: Wed, 10 Sep 2008 06:45:59 -0400 (EDT) Subject: duplicate packet Message-ID: <473679.44924.qm@web57413.mail.re1.yahoo.com> Hi all When I ping the ip, I get the duplicate I check the ip is just one. Why it happens? Thank you 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.344 ms 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.401 ms (DUP!) 64 bytes from 192.168.0.95: icmp_seq=2 ttl=63 time=0.296 ms 64 bytes from 192.168.0.95: icmp_seq=2 ttl=63 time=0.328 ms (DUP!) 64 bytes from 192.168.0.95: icmp_seq=3 ttl=63 time=0.291 ms 64 bytes from 192.168.0.95: icmp_seq=3 ttl=63 time=0.316 ms (DUP!) 64 bytes from 192.168.0.95: icmp_seq=4 ttl=63 time=0.279 ms 64 bytes from 192.168.0.95: icmp_seq=4 ttl=63 time=0.309 ms (DUP!) 64 bytes from 192.168.0.95: icmp_seq=5 ttl=63 time=0.271 ms 64 bytes from 192.168.0.95: icmp_seq=5 ttl=63 time=0.299 ms (DUP!) --------------------------------- Yahoo! Canada Toolbar : Search from anywhere on the web and bookmark your favourite sites. Download it now! From rs at seastrom.com Wed Sep 10 06:38:46 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Wed, 10 Sep 2008 07:38:46 -0400 Subject: ingress SMTP In-Reply-To: (Mark Foster's message of "Fri, 5 Sep 2008 21:12:03 +1200 (NZST)") References: <20080904185730.GC14670@redline.kinz.org> <12462.119.15.0.26.1220571234.squirrel@webmail.blakjak.net> <200809050921.17516.simonw@zynet.net> Message-ID: <864p4oz0vt.fsf@seastrom.com> Mark Foster writes: > On Fri, 5 Sep 2008, Mikael Abrahamsson wrote: >> >> We don't allow most of our residential customer base to speak SMTP >> TCP/25 to anywhere at all (and we have millions of them). Wish more >> ISPs would do the same. >> > > Probably fair enough, if you as an ISP can get away with enforcing > this sort of policy then so much the better. > > However relaying through your own ISPs 25/tcp should surely then make > it relatively easy for noise to be tracked down and nailed at the > source - by ISPs? (Do abuse@ desks investigate spam these days?) As others have noted, intercepting 25 breaks SPF. It also gratuitously creates weird anomalous behaviour that is much harder for a reasonably clued person to debug than a simple blocked port, so it's more likely to buy you a help desk call (with a subtle problem that your level 1 folks probably can't get sorted anyway). Perhaps you aren't in a position where you have to care about the balance sheets, but keeping the load off the help desk is a wonderful thing to do in terms of cost control. Doing traffic analysis looking for noise is just extra work for your abuse people - when I was setting policy for this sort of thing we put a cap at 1000 discrete destinations per day per authenticated user (with a daily report of who'd busted it, and most days the report was 0) and only once ran into a problem where someone was legitimately trying to send mail to a bajillion people and called the help desk. -r From fweimer at bfk.de Wed Sep 10 06:43:19 2008 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 10 Sep 2008 13:43:19 +0200 Subject: duplicate packet In-Reply-To: <473679.44924.qm@web57413.mail.re1.yahoo.com> (chloe K.'s message of "Wed, 10 Sep 2008 06:45:59 -0400 (EDT)") References: <473679.44924.qm@web57413.mail.re1.yahoo.com> Message-ID: <82wshk8bvs.fsf@mid.bfk.de> * chloe K.: > When I ping the ip, I get the duplicate > > I check the ip is just one. Why it happens? Are the source and target on the same subnet? Have you checked the source MAC address of the response? -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From darden at armc.org Wed Sep 10 07:01:32 2008 From: darden at armc.org (Darden, Patrick S.) Date: Wed, 10 Sep 2008 08:01:32 -0400 Subject: duplicate packet In-Reply-To: <473679.44924.qm@web57413.mail.re1.yahoo.com> Message-ID: Check your ARP tables, local and on intervening switches/routers. Make sure there are no duplicate entries for that IP. If you note the response time, the second packet is always higher which might be indicative. I would also check for a botched MITM a la C&A. Even if there is no obvious ARP table manglement, you might try flushing the local and intervening caches. Try the ping from another host, another subnet, another segment, get more info. --p -----Original Message----- From: chloe K [mailto:chloekcy2000 at yahoo.ca] Sent: Wednesday, September 10, 2008 6:46 AM To: nanog at nanog.org Subject: duplicate packet Hi all When I ping the ip, I get the duplicate I check the ip is just one. Why it happens? Thank you 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.344 ms 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.401 ms (DUP!) 64 bytes from 192.168.0.95: icmp_seq=2 ttl=63 time=0.296 ms 64 bytes from 192.168.0.95: icmp_seq=2 ttl=63 time=0.328 ms (DUP!) 64 bytes from 192.168.0.95: icmp_seq=3 ttl=63 time=0.291 ms 64 bytes from 192.168.0.95: icmp_seq=3 ttl=63 time=0.316 ms (DUP!) 64 bytes from 192.168.0.95: icmp_seq=4 ttl=63 time=0.279 ms 64 bytes from 192.168.0.95: icmp_seq=4 ttl=63 time=0.309 ms (DUP!) 64 bytes from 192.168.0.95: icmp_seq=5 ttl=63 time=0.271 ms 64 bytes from 192.168.0.95: icmp_seq=5 ttl=63 time=0.299 ms (DUP!) --------------------------------- Yahoo! Canada Toolbar : Search from anywhere on the web and bookmark your favourite sites. Download it now! From eric at atlantech.net Wed Sep 10 07:06:02 2008 From: eric at atlantech.net (Eric Van Tol) Date: Wed, 10 Sep 2008 08:06:02 -0400 Subject: duplicate packet In-Reply-To: <473679.44924.qm@web57413.mail.re1.yahoo.com> References: <473679.44924.qm@web57413.mail.re1.yahoo.com> Message-ID: <2C05E949E19A9146AF7BDF9D44085B86350AECC45F@exchange.aoihq.local> > -----Original Message----- > From: chloe K [mailto:chloekcy2000 at yahoo.ca] > Sent: Wednesday, September 10, 2008 6:46 AM > To: nanog at nanog.org > Subject: duplicate packet > > Hi all > > When I ping the ip, I get the duplicate > > I check the ip is just one. Why it happens? > > Thank you > > 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.344 ms > 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.401 ms (DUP!) > 64 bytes from 192.168.0.95: icmp_seq=2 ttl=63 time=0.296 ms > 64 bytes from 192.168.0.95: icmp_seq=2 ttl=63 time=0.328 ms (DUP!) > 64 bytes from 192.168.0.95: icmp_seq=3 ttl=63 time=0.291 ms > 64 bytes from 192.168.0.95: icmp_seq=3 ttl=63 time=0.316 ms (DUP!) > 64 bytes from 192.168.0.95: icmp_seq=4 ttl=63 time=0.279 ms > 64 bytes from 192.168.0.95: icmp_seq=4 ttl=63 time=0.309 ms (DUP!) > 64 bytes from 192.168.0.95: icmp_seq=5 ttl=63 time=0.271 ms > 64 bytes from 192.168.0.95: icmp_seq=5 ttl=63 time=0.299 ms (DUP!) Check to see whether or not the port connected to that host is mirrored or in a SPAN VLAN. Misconfiguration on an analyzer server can cause duplicate traffic to be generated. -evt From jlewis at lewis.org Wed Sep 10 07:11:18 2008 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 10 Sep 2008 08:11:18 -0400 (EDT) Subject: duplicate packet In-Reply-To: <473679.44924.qm@web57413.mail.re1.yahoo.com> References: <473679.44924.qm@web57413.mail.re1.yahoo.com> Message-ID: On Wed, 10 Sep 2008, chloe K wrote: > When I ping the ip, I get the duplicate > > I check the ip is just one. Why it happens? > > 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.344 ms > 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.401 ms (DUP!) Not enough information has been given. Just hope it's not being caused by a Level3/Sprint circuit...ours is still doing this (when I change back to HDLC) and they just don't freaking care. Sometimes I wish I worked for a big telco so I could leave things broken and say "hey, I'm the telco, I don't have to care." Maybe we should refuse to pay for the affected DS3 and see if that gets more attention. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From sabt at sabt.net Wed Sep 10 07:11:48 2008 From: sabt at sabt.net (Sebastian Abt) Date: Wed, 10 Sep 2008 14:11:48 +0200 Subject: duplicate packet In-Reply-To: <473679.44924.qm@web57413.mail.re1.yahoo.com> References: <473679.44924.qm@web57413.mail.re1.yahoo.com> Message-ID: <20080910121148.GA4491@sephina.sabt.net> * chloe K wrote: > When I ping the ip, I get the duplicate > > 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.344 ms > 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.401 ms (DUP!) ^^^^^^^^^^^^ What's your netmask? Is 192.168.0.95 your net's broadcast address? sebastian -- SABT-RIPE PGPKEY-D008DA9C From tims at donet.com Wed Sep 10 07:26:52 2008 From: tims at donet.com (Tim Sanderson) Date: Wed, 10 Sep 2008 08:26:52 -0400 Subject: duplicate packet In-Reply-To: References: <473679.44924.qm@web57413.mail.re1.yahoo.com> Message-ID: Instead, dispute the bill and then when they won't credit you for not giving you what you ordered, open a complaint with the state public utilities commission. It may get you some movement on the issue. -- Tim Sanderson, network administrator tims at donet.com -----Original Message----- From: Jon Lewis [mailto:jlewis at lewis.org] Sent: Wednesday, September 10, 2008 8:11 AM To: chloe K Cc: nanog at nanog.org Subject: Re: duplicate packet On Wed, 10 Sep 2008, chloe K wrote: > When I ping the ip, I get the duplicate > > I check the ip is just one. Why it happens? > > 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.344 ms > 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.401 ms (DUP!) Not enough information has been given. Just hope it's not being caused by a Level3/Sprint circuit...ours is still doing this (when I change back to HDLC) and they just don't freaking care. Sometimes I wish I worked for a big telco so I could leave things broken and say "hey, I'm the telco, I don't have to care." Maybe we should refuse to pay for the affected DS3 and see if that gets more attention. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From LarrySheldon at cox.net Wed Sep 10 08:10:20 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Wed, 10 Sep 2008 08:10:20 -0500 Subject: duplicate packet In-Reply-To: <20080910121148.GA4491@sephina.sabt.net> References: <473679.44924.qm@web57413.mail.re1.yahoo.com> <20080910121148.GA4491@sephina.sabt.net> Message-ID: <48C7C73C.7000900@cox.net> Sebastian Abt wrote: > * chloe K wrote: >> When I ping the ip, I get the duplicate >> >> 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.344 ms >> 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.401 ms (DUP!) > ^^^^^^^^^^^^ > What's your netmask? Is 192.168.0.95 your net's broadcast address? Ohhh! Nice catch! From mpetach at netflight.com Wed Sep 10 08:13:18 2008 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 10 Sep 2008 06:13:18 -0700 Subject: Yahoo! mail admins? In-Reply-To: References: Message-ID: <63ac96a50809100613k3f9f2499p9270dbc5b7a82533@mail.gmail.com> On 9/10/08, Paul Kelly :: Blacknight wrote: > Hi There, > > Are there any Yahoo! e-mail admins on the list? We're having some issues at times delivering e-mail to yahoo.co.uk and sometimes some of the other yahoo networks. > Probably not--but folks can probably get the message to the right ears. Let me know off list the nature of the issue (layer 3 reachability vs layer 7 application error messages) and I'll see what I can do to get the message to the right recipients. Thanks! Matt > Thanks, > > 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 > > From hobbit at avian.org Wed Sep 10 07:35:24 2008 From: hobbit at avian.org (*Hobbit*) Date: Wed, 10 Sep 2008 12:35:24 +0000 (GMT) Subject: ingress SMTP Message-ID: <20080910123524.3D97E7808@relayer.avian.org> I am completely convinced that abuse@ in most big providers is a black hole with an autoresponder hung off it, and nothing ever gets done with complaints. NO HUMAN ever sees them, and even if they did, most of the humans at these outfits wouldn't recognize a Received: header if it bit them in the ass. I invite and welcome anyone from the "big boyz" I named in the original question -- verizon, comcast, roadrunner, charter, bellsouth/SBC, and now Google -- *especially* Gmail, given that counterproductive "privacy" policy we noted -- to inform me otherwise. _H* From leo.vegoda at icann.org Wed Sep 10 09:38:44 2008 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 10 Sep 2008 07:38:44 -0700 Subject: New (2-byte) ASN Allocation for RIPE NCC Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This is to confirm that the IANA has allocated one 2-byte ASN block to the RIPE NCC: 48128-49151 Assigned by RIPE NCC whois.ripe.net 2008-09-09 A note of the allocation has been made at: http://www.iana.org/assignments/as-numbers/as-numbers.xml http://www.iana.org/assignments/as-numbers/as-numbers.xhtml http://www.iana.org/assignments/as-numbers/as-numbers.txt Thank you and best regards, Leo Vegoda leo.vegoda at icann.org ******************************************* Internet Assigned Numbers Authority (IANA) 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 Phone: +1-310-823-9358 Fax: +1-310-823-8649 ******************************************* -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFIx9suvBLymJnAzRwRAgnkAKDDxJCilYy0aErDQtQQFEcsCKG/QwCgi+Ao 029EI3Ful4LKPXMJEUGKs3g= =7EeD -----END PGP SIGNATURE----- From jrhett at netconsonance.com Wed Sep 10 14:47:26 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Wed, 10 Sep 2008 12:47:26 -0700 Subject: Teleglobe appears to be spam-source zombie network? Message-ID: <03F411FC-74D6-48CA-84FC-16706B05BADE@netconsonance.com> We started getting a flood of autobot spam to our listed abuse mailbox about an hour ago out of Teleglobe. Trying to find someone to shut this down has found that 1. Teleglobe has no listed abuse contacts for any of their netblocks 2. The few of their records which have listed e-mail addresses all bounce 3. All listed phone numbers on any netblocks we can find are invalid Any chance that RIPE is more strigent than ARIN and would pull their netblocks until they fix this stuff? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From nuno.vieira at nfsi.pt Wed Sep 10 14:51:09 2008 From: nuno.vieira at nfsi.pt (Nuno Vieira - nfsi telecom) Date: Wed, 10 Sep 2008 20:51:09 +0100 (WEST) Subject: Teleglobe appears to be spam-source zombie network? In-Reply-To: <03F411FC-74D6-48CA-84FC-16706B05BADE@netconsonance.com> Message-ID: <823080104.21701221076269458.JavaMail.root@zimbra.nfsi.pt> Try reach them at CAbuse at tatacommunications.com cheers, --- Nuno Vieira nfsi telecom, lda. nuno.vieira at nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ ----- "Jo Rhett" wrote: > We started getting a flood of autobot spam to our listed abuse mailbox > > about an hour ago out of Teleglobe. Trying to find someone to shut > this down has found that > > 1. Teleglobe has no listed abuse contacts for any of their netblocks > 2. The few of their records which have listed e-mail addresses all > bounce > 3. All listed phone numbers on any netblocks we can find are invalid > > Any chance that RIPE is more strigent than ARIN and would pull their > > netblocks until they fix this stuff? > > -- > Jo Rhett > Net Consonance : consonant endings by net philanthropy, open source > and other randomness From tme at multicasttech.com Wed Sep 10 14:59:35 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Wed, 10 Sep 2008 15:59:35 -0400 Subject: Teleglobe appears to be spam-source zombie network? In-Reply-To: <823080104.21701221076269458.JavaMail.root@zimbra.nfsi.pt> References: <823080104.21701221076269458.JavaMail.root@zimbra.nfsi.pt> Message-ID: <0B1059FF-6187-4212-A666-3124BFB38E88@multicasttech.com> On Sep 10, 2008, at 3:51 PM, Nuno Vieira - nfsi telecom wrote: > Try reach them at CAbuse at tatacommunications.com > Yes - all my teleglobe contacts went over to Tata email addresses during the summer. Regards Marshall > cheers, > --- > Nuno Vieira > nfsi telecom, lda. > > nuno.vieira at nfsi.pt > Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 > http://www.nfsi.pt/ > > > > ----- "Jo Rhett" wrote: > >> We started getting a flood of autobot spam to our listed abuse >> mailbox >> >> about an hour ago out of Teleglobe. Trying to find someone to shut >> this down has found that >> >> 1. Teleglobe has no listed abuse contacts for any of their netblocks >> 2. The few of their records which have listed e-mail addresses all >> bounce >> 3. All listed phone numbers on any netblocks we can find are invalid >> >> Any chance that RIPE is more strigent than ARIN and would pull their >> >> netblocks until they fix this stuff? >> >> -- >> Jo Rhett >> Net Consonance : consonant endings by net philanthropy, open source >> and other randomness > From jra at baylink.com Wed Sep 10 15:50:15 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Wed, 10 Sep 2008 16:50:15 -0400 Subject: L(3) / 4/8 / multihoming Message-ID: <20080910205015.GL10282@cgi.jachomes.com> I see in http://www.onesc.net/communities/as3356/ that L3 doesn't permit customers to multihome the 4/8 space that they inherited from BBN, via GTE, etc, ad nauseum... and I'm curious whether anyone knows why? It sounds like something there might be an interesting story in... Off-list is fine; I'll summarize if anyone else cares. 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 fabianb at cs.northwestern.edu Wed Sep 10 15:59:05 2008 From: fabianb at cs.northwestern.edu (Fabian E. Bustamante) Date: Wed, 10 Sep 2008 15:59:05 -0500 Subject: Validating network issues in a Comcast AS Message-ID: <48C83519.8080804@cs.northwestern.edu> Hello, I was wondering if anybody could put me in touch (perhaps they are already listening) with a contact point for Comcast Cable Comm. As part of some research work we are doing, we identified some issues in their network (in particular AS33657) and would love to confirm them. I did email the notification contact, but got some silly automatic response. Thanks a lot! an optimistic academic -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Fabian E. Bustamante, Associate Professor EECS, Northwestern U. Technological Institute L465 2145 Sheridan Road, Evanston, IL 60208 www.aqualab.cs.northwestern.edu From bvaz at ipercast.net Wed Sep 10 16:12:17 2008 From: bvaz at ipercast.net (Bruno VAZ) Date: Wed, 10 Sep 2008 21:12:17 +0000 Subject: NANOG Digest, Vol 8, Issue 38 In-Reply-To: References: Message-ID: <1199748-1221081143-cardhu_decombobulator_blackberry.rim.net-204831413-@bxe042.bisx.produk.on.blackberry> --- [Message envoy? a partir d'un mobile] Bruno VAZ Ipercast Operations 40, Rue de PARIS / 92100 Boulogne-Billancourt Tel +33 1 72 77 70 87 Mailbvaz at ipercast.net -----Original Message----- From: nanog-request at nanog.org Date: Wed, 10 Sep 2008 19:59:40 To: Subject: NANOG Digest, Vol 8, Issue 38 Send NANOG mailing list submissions to nanog at nanog.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-request at nanog.org You can reach the person managing the list at nanog-owner at nanog.org When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: 1. RE: duplicate packet (Darden, Patrick S.) 2. RE: duplicate packet (Eric Van Tol) 3. Re: duplicate packet (Jon Lewis) 4. Re: duplicate packet (Sebastian Abt) 5. RE: duplicate packet (Tim Sanderson) 6. Re: duplicate packet (Laurence F. Sheldon, Jr.) 7. Re: Yahoo! mail admins? (Matthew Petach) 8. Re: ingress SMTP (*Hobbit*) 9. New (2-byte) ASN Allocation for RIPE NCC (Leo Vegoda) 10. Teleglobe appears to be spam-source zombie network? (Jo Rhett) 11. Re: Teleglobe appears to be spam-source zombie network? (Nuno Vieira - nfsi telecom) 12. Re: Teleglobe appears to be spam-source zombie network? (Marshall Eubanks) ---------------------------------------------------------------------- Message: 1 Date: Wed, 10 Sep 2008 08:01:32 -0400 From: "Darden, Patrick S." Subject: RE: duplicate packet To: "chloe K" , Message-ID: Content-Type: text/plain; charset="iso-8859-1" Check your ARP tables, local and on intervening switches/routers. Make sure there are no duplicate entries for that IP. If you note the response time, the second packet is always higher which might be indicative. I would also check for a botched MITM a la C&A. Even if there is no obvious ARP table manglement, you might try flushing the local and intervening caches. Try the ping from another host, another subnet, another segment, get more info. --p -----Original Message----- From: chloe K [mailto:chloekcy2000 at yahoo.ca] Sent: Wednesday, September 10, 2008 6:46 AM To: nanog at nanog.org Subject: duplicate packet Hi all When I ping the ip, I get the duplicate I check the ip is just one. Why it happens? Thank you 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.344 ms 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.401 ms (DUP!) 64 bytes from 192.168.0.95: icmp_seq=2 ttl=63 time=0.296 ms 64 bytes from 192.168.0.95: icmp_seq=2 ttl=63 time=0.328 ms (DUP!) 64 bytes from 192.168.0.95: icmp_seq=3 ttl=63 time=0.291 ms 64 bytes from 192.168.0.95: icmp_seq=3 ttl=63 time=0.316 ms (DUP!) 64 bytes from 192.168.0.95: icmp_seq=4 ttl=63 time=0.279 ms 64 bytes from 192.168.0.95: icmp_seq=4 ttl=63 time=0.309 ms (DUP!) 64 bytes from 192.168.0.95: icmp_seq=5 ttl=63 time=0.271 ms 64 bytes from 192.168.0.95: icmp_seq=5 ttl=63 time=0.299 ms (DUP!) --------------------------------- Yahoo! Canada Toolbar : Search from anywhere on the web and bookmark your favourite sites. Download it now! ------------------------------ Message: 2 Date: Wed, 10 Sep 2008 08:06:02 -0400 From: Eric Van Tol Subject: RE: duplicate packet To: 'chloe K' , "nanog at nanog.org" Message-ID: <2C05E949E19A9146AF7BDF9D44085B86350AECC45F at exchange.aoihq.local> Content-Type: text/plain; charset="us-ascii" > -----Original Message----- > From: chloe K [mailto:chloekcy2000 at yahoo.ca] > Sent: Wednesday, September 10, 2008 6:46 AM > To: nanog at nanog.org > Subject: duplicate packet > > Hi all > > When I ping the ip, I get the duplicate > > I check the ip is just one. Why it happens? > > Thank you > > 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.344 ms > 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.401 ms (DUP!) > 64 bytes from 192.168.0.95: icmp_seq=2 ttl=63 time=0.296 ms > 64 bytes from 192.168.0.95: icmp_seq=2 ttl=63 time=0.328 ms (DUP!) > 64 bytes from 192.168.0.95: icmp_seq=3 ttl=63 time=0.291 ms > 64 bytes from 192.168.0.95: icmp_seq=3 ttl=63 time=0.316 ms (DUP!) > 64 bytes from 192.168.0.95: icmp_seq=4 ttl=63 time=0.279 ms > 64 bytes from 192.168.0.95: icmp_seq=4 ttl=63 time=0.309 ms (DUP!) > 64 bytes from 192.168.0.95: icmp_seq=5 ttl=63 time=0.271 ms > 64 bytes from 192.168.0.95: icmp_seq=5 ttl=63 time=0.299 ms (DUP!) Check to see whether or not the port connected to that host is mirrored or in a SPAN VLAN. Misconfiguration on an analyzer server can cause duplicate traffic to be generated. -evt ------------------------------ Message: 3 Date: Wed, 10 Sep 2008 08:11:18 -0400 (EDT) From: Jon Lewis Subject: Re: duplicate packet To: chloe K Cc: nanog at nanog.org Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Wed, 10 Sep 2008, chloe K wrote: > When I ping the ip, I get the duplicate > > I check the ip is just one. Why it happens? > > 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.344 ms > 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.401 ms (DUP!) Not enough information has been given. Just hope it's not being caused by a Level3/Sprint circuit...ours is still doing this (when I change back to HDLC) and they just don't freaking care. Sometimes I wish I worked for a big telco so I could leave things broken and say "hey, I'm the telco, I don't have to care." Maybe we should refuse to pay for the affected DS3 and see if that gets more attention. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ ------------------------------ Message: 4 Date: Wed, 10 Sep 2008 14:11:48 +0200 From: Sebastian Abt Subject: Re: duplicate packet To: chloe K Cc: nanog at nanog.org Message-ID: <20080910121148.GA4491 at sephina.sabt.net> Content-Type: text/plain; charset=us-ascii * chloe K wrote: > When I ping the ip, I get the duplicate > > 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.344 ms > 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.401 ms (DUP!) ^^^^^^^^^^^^ What's your netmask? Is 192.168.0.95 your net's broadcast address? sebastian -- SABT-RIPE PGPKEY-D008DA9C ------------------------------ Message: 5 Date: Wed, 10 Sep 2008 08:26:52 -0400 From: Tim Sanderson Subject: RE: duplicate packet To: "nanog at nanog.org" Message-ID: Content-Type: text/plain; charset="us-ascii" Instead, dispute the bill and then when they won't credit you for not giving you what you ordered, open a complaint with the state public utilities commission. It may get you some movement on the issue. -- Tim Sanderson, network administrator tims at donet.com -----Original Message----- From: Jon Lewis [mailto:jlewis at lewis.org] Sent: Wednesday, September 10, 2008 8:11 AM To: chloe K Cc: nanog at nanog.org Subject: Re: duplicate packet On Wed, 10 Sep 2008, chloe K wrote: > When I ping the ip, I get the duplicate > > I check the ip is just one. Why it happens? > > 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.344 ms > 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.401 ms (DUP!) Not enough information has been given. Just hope it's not being caused by a Level3/Sprint circuit...ours is still doing this (when I change back to HDLC) and they just don't freaking care. Sometimes I wish I worked for a big telco so I could leave things broken and say "hey, I'm the telco, I don't have to care." Maybe we should refuse to pay for the affected DS3 and see if that gets more attention. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ ------------------------------ Message: 6 Date: Wed, 10 Sep 2008 08:10:20 -0500 From: "Laurence F. Sheldon, Jr." Subject: Re: duplicate packet Cc: nanog at nanog.org Message-ID: <48C7C73C.7000900 at cox.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sebastian Abt wrote: > * chloe K wrote: >> When I ping the ip, I get the duplicate >> >> 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.344 ms >> 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.401 ms (DUP!) > ^^^^^^^^^^^^ > What's your netmask? Is 192.168.0.95 your net's broadcast address? Ohhh! Nice catch! ------------------------------ Message: 7 Date: Wed, 10 Sep 2008 06:13:18 -0700 From: "Matthew Petach" Subject: Re: Yahoo! mail admins? To: "Paul Kelly :: Blacknight" Cc: "nanog at nanog.org" Message-ID: <63ac96a50809100613k3f9f2499p9270dbc5b7a82533 at mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On 9/10/08, Paul Kelly :: Blacknight wrote: > Hi There, > > Are there any Yahoo! e-mail admins on the list? We're having some issues at times delivering e-mail to yahoo.co.uk and sometimes some of the other yahoo networks. > Probably not--but folks can probably get the message to the right ears. Let me know off list the nature of the issue (layer 3 reachability vs layer 7 application error messages) and I'll see what I can do to get the message to the right recipients. Thanks! Matt > Thanks, > > 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 > > ------------------------------ Message: 8 Date: Wed, 10 Sep 2008 12:35:24 +0000 (GMT) From: hobbit at avian.org (*Hobbit*) Subject: Re: ingress SMTP To: nanog at nanog.org Message-ID: <20080910123524.3D97E7808 at relayer.avian.org> I am completely convinced that abuse@ in most big providers is a black hole with an autoresponder hung off it, and nothing ever gets done with complaints. NO HUMAN ever sees them, and even if they did, most of the humans at these outfits wouldn't recognize a Received: header if it bit them in the ass. I invite and welcome anyone from the "big boyz" I named in the original question -- verizon, comcast, roadrunner, charter, bellsouth/SBC, and now Google -- *especially* Gmail, given that counterproductive "privacy" policy we noted -- to inform me otherwise. _H* ------------------------------ Message: 9 Date: Wed, 10 Sep 2008 07:38:44 -0700 From: Leo Vegoda Subject: New (2-byte) ASN Allocation for RIPE NCC To: Leo Vegoda Message-ID: Content-Type: text/plain; charset="iso-8859-1" -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This is to confirm that the IANA has allocated one 2-byte ASN block to the RIPE NCC: 48128-49151 Assigned by RIPE NCC whois.ripe.net 2008-09-09 A note of the allocation has been made at: http://www.iana.org/assignments/as-numbers/as-numbers.xml http://www.iana.org/assignments/as-numbers/as-numbers.xhtml http://www.iana.org/assignments/as-numbers/as-numbers.txt Thank you and best regards, Leo Vegoda leo.vegoda at icann.org ******************************************* Internet Assigned Numbers Authority (IANA) 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 Phone: +1-310-823-9358 Fax: +1-310-823-8649 ******************************************* -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFIx9suvBLymJnAzRwRAgnkAKDDxJCilYy0aErDQtQQFEcsCKG/QwCgi+Ao 029EI3Ful4LKPXMJEUGKs3g= =7EeD -----END PGP SIGNATURE----- ------------------------------ Message: 10 Date: Wed, 10 Sep 2008 12:47:26 -0700 From: Jo Rhett Subject: Teleglobe appears to be spam-source zombie network? To: nanog Message-ID: <03F411FC-74D6-48CA-84FC-16706B05BADE at netconsonance.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes We started getting a flood of autobot spam to our listed abuse mailbox about an hour ago out of Teleglobe. Trying to find someone to shut this down has found that 1. Teleglobe has no listed abuse contacts for any of their netblocks 2. The few of their records which have listed e-mail addresses all bounce 3. All listed phone numbers on any netblocks we can find are invalid Any chance that RIPE is more strigent than ARIN and would pull their netblocks until they fix this stuff? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ------------------------------ Message: 11 Date: Wed, 10 Sep 2008 20:51:09 +0100 (WEST) From: Nuno Vieira - nfsi telecom Subject: Re: Teleglobe appears to be spam-source zombie network? To: Jo Rhett Cc: nanog Message-ID: <823080104.21701221076269458.JavaMail.root at zimbra.nfsi.pt> Content-Type: text/plain; charset=utf-8 Try reach them at CAbuse at tatacommunications.com cheers, --- Nuno Vieira nfsi telecom, lda. nuno.vieira at nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ ----- "Jo Rhett" wrote: > We started getting a flood of autobot spam to our listed abuse mailbox > > about an hour ago out of Teleglobe. Trying to find someone to shut > this down has found that > > 1. Teleglobe has no listed abuse contacts for any of their netblocks > 2. The few of their records which have listed e-mail addresses all > bounce > 3. All listed phone numbers on any netblocks we can find are invalid > > Any chance that RIPE is more strigent than ARIN and would pull their > > netblocks until they fix this stuff? > > -- > Jo Rhett > Net Consonance : consonant endings by net philanthropy, open source > and other randomness ------------------------------ Message: 12 Date: Wed, 10 Sep 2008 15:59:35 -0400 From: Marshall Eubanks Subject: Re: Teleglobe appears to be spam-source zombie network? To: Nuno Vieira - nfsi telecom Cc: nanog Message-ID: <0B1059FF-6187-4212-A666-3124BFB38E88 at multicasttech.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes On Sep 10, 2008, at 3:51 PM, Nuno Vieira - nfsi telecom wrote: > Try reach them at CAbuse at tatacommunications.com > Yes - all my teleglobe contacts went over to Tata email addresses during the summer. Regards Marshall > cheers, > --- > Nuno Vieira > nfsi telecom, lda. > > nuno.vieira at nfsi.pt > Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 > http://www.nfsi.pt/ > > > > ----- "Jo Rhett" wrote: > >> We started getting a flood of autobot spam to our listed abuse >> mailbox >> >> about an hour ago out of Teleglobe. Trying to find someone to shut >> this down has found that >> >> 1. Teleglobe has no listed abuse contacts for any of their netblocks >> 2. The few of their records which have listed e-mail addresses all >> bounce >> 3. All listed phone numbers on any netblocks we can find are invalid >> >> Any chance that RIPE is more strigent than ARIN and would pull their >> >> netblocks until they fix this stuff? >> >> -- >> Jo Rhett >> Net Consonance : consonant endings by net philanthropy, open source >> and other randomness > ------------------------------ _______________________________________________ NANOG mailing list NANOG at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog End of NANOG Digest, Vol 8, Issue 38 ************************************ From bvaz at ipercast.net Wed Sep 10 16:13:11 2008 From: bvaz at ipercast.net (Bruno VAZ) Date: Wed, 10 Sep 2008 21:13:11 +0000 Subject: NANOG Digest, Vol 8, Issue 38 In-Reply-To: References: Message-ID: <486935966-1221081197-cardhu_decombobulator_blackberry.rim.net-585443038-@bxe042.bisx.produk.on.blackberry> --- [Message envoy? a partir d'un mobile] Bruno VAZ Ipercast Operations 40, Rue de PARIS / 92100 Boulogne-Billancourt Tel +33 1 72 77 70 87 Mailbvaz at ipercast.net -----Original Message----- From: nanog-request at nanog.org Date: Wed, 10 Sep 2008 19:59:40 To: Subject: NANOG Digest, Vol 8, Issue 38 Send NANOG mailing list submissions to nanog at nanog.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-request at nanog.org You can reach the person managing the list at nanog-owner at nanog.org When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: 1. RE: duplicate packet (Darden, Patrick S.) 2. RE: duplicate packet (Eric Van Tol) 3. Re: duplicate packet (Jon Lewis) 4. Re: duplicate packet (Sebastian Abt) 5. RE: duplicate packet (Tim Sanderson) 6. Re: duplicate packet (Laurence F. Sheldon, Jr.) 7. Re: Yahoo! mail admins? (Matthew Petach) 8. Re: ingress SMTP (*Hobbit*) 9. New (2-byte) ASN Allocation for RIPE NCC (Leo Vegoda) 10. Teleglobe appears to be spam-source zombie network? (Jo Rhett) 11. Re: Teleglobe appears to be spam-source zombie network? (Nuno Vieira - nfsi telecom) 12. Re: Teleglobe appears to be spam-source zombie network? (Marshall Eubanks) ---------------------------------------------------------------------- Message: 1 Date: Wed, 10 Sep 2008 08:01:32 -0400 From: "Darden, Patrick S." Subject: RE: duplicate packet To: "chloe K" , Message-ID: Content-Type: text/plain; charset="iso-8859-1" Check your ARP tables, local and on intervening switches/routers. Make sure there are no duplicate entries for that IP. If you note the response time, the second packet is always higher which might be indicative. I would also check for a botched MITM a la C&A. Even if there is no obvious ARP table manglement, you might try flushing the local and intervening caches. Try the ping from another host, another subnet, another segment, get more info. --p -----Original Message----- From: chloe K [mailto:chloekcy2000 at yahoo.ca] Sent: Wednesday, September 10, 2008 6:46 AM To: nanog at nanog.org Subject: duplicate packet Hi all When I ping the ip, I get the duplicate I check the ip is just one. Why it happens? Thank you 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.344 ms 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.401 ms (DUP!) 64 bytes from 192.168.0.95: icmp_seq=2 ttl=63 time=0.296 ms 64 bytes from 192.168.0.95: icmp_seq=2 ttl=63 time=0.328 ms (DUP!) 64 bytes from 192.168.0.95: icmp_seq=3 ttl=63 time=0.291 ms 64 bytes from 192.168.0.95: icmp_seq=3 ttl=63 time=0.316 ms (DUP!) 64 bytes from 192.168.0.95: icmp_seq=4 ttl=63 time=0.279 ms 64 bytes from 192.168.0.95: icmp_seq=4 ttl=63 time=0.309 ms (DUP!) 64 bytes from 192.168.0.95: icmp_seq=5 ttl=63 time=0.271 ms 64 bytes from 192.168.0.95: icmp_seq=5 ttl=63 time=0.299 ms (DUP!) --------------------------------- Yahoo! Canada Toolbar : Search from anywhere on the web and bookmark your favourite sites. Download it now! ------------------------------ Message: 2 Date: Wed, 10 Sep 2008 08:06:02 -0400 From: Eric Van Tol Subject: RE: duplicate packet To: 'chloe K' , "nanog at nanog.org" Message-ID: <2C05E949E19A9146AF7BDF9D44085B86350AECC45F at exchange.aoihq.local> Content-Type: text/plain; charset="us-ascii" > -----Original Message----- > From: chloe K [mailto:chloekcy2000 at yahoo.ca] > Sent: Wednesday, September 10, 2008 6:46 AM > To: nanog at nanog.org > Subject: duplicate packet > > Hi all > > When I ping the ip, I get the duplicate > > I check the ip is just one. Why it happens? > > Thank you > > 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.344 ms > 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.401 ms (DUP!) > 64 bytes from 192.168.0.95: icmp_seq=2 ttl=63 time=0.296 ms > 64 bytes from 192.168.0.95: icmp_seq=2 ttl=63 time=0.328 ms (DUP!) > 64 bytes from 192.168.0.95: icmp_seq=3 ttl=63 time=0.291 ms > 64 bytes from 192.168.0.95: icmp_seq=3 ttl=63 time=0.316 ms (DUP!) > 64 bytes from 192.168.0.95: icmp_seq=4 ttl=63 time=0.279 ms > 64 bytes from 192.168.0.95: icmp_seq=4 ttl=63 time=0.309 ms (DUP!) > 64 bytes from 192.168.0.95: icmp_seq=5 ttl=63 time=0.271 ms > 64 bytes from 192.168.0.95: icmp_seq=5 ttl=63 time=0.299 ms (DUP!) Check to see whether or not the port connected to that host is mirrored or in a SPAN VLAN. Misconfiguration on an analyzer server can cause duplicate traffic to be generated. -evt ------------------------------ Message: 3 Date: Wed, 10 Sep 2008 08:11:18 -0400 (EDT) From: Jon Lewis Subject: Re: duplicate packet To: chloe K Cc: nanog at nanog.org Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Wed, 10 Sep 2008, chloe K wrote: > When I ping the ip, I get the duplicate > > I check the ip is just one. Why it happens? > > 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.344 ms > 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.401 ms (DUP!) Not enough information has been given. Just hope it's not being caused by a Level3/Sprint circuit...ours is still doing this (when I change back to HDLC) and they just don't freaking care. Sometimes I wish I worked for a big telco so I could leave things broken and say "hey, I'm the telco, I don't have to care." Maybe we should refuse to pay for the affected DS3 and see if that gets more attention. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ ------------------------------ Message: 4 Date: Wed, 10 Sep 2008 14:11:48 +0200 From: Sebastian Abt Subject: Re: duplicate packet To: chloe K Cc: nanog at nanog.org Message-ID: <20080910121148.GA4491 at sephina.sabt.net> Content-Type: text/plain; charset=us-ascii * chloe K wrote: > When I ping the ip, I get the duplicate > > 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.344 ms > 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.401 ms (DUP!) ^^^^^^^^^^^^ What's your netmask? Is 192.168.0.95 your net's broadcast address? sebastian -- SABT-RIPE PGPKEY-D008DA9C ------------------------------ Message: 5 Date: Wed, 10 Sep 2008 08:26:52 -0400 From: Tim Sanderson Subject: RE: duplicate packet To: "nanog at nanog.org" Message-ID: Content-Type: text/plain; charset="us-ascii" Instead, dispute the bill and then when they won't credit you for not giving you what you ordered, open a complaint with the state public utilities commission. It may get you some movement on the issue. -- Tim Sanderson, network administrator tims at donet.com -----Original Message----- From: Jon Lewis [mailto:jlewis at lewis.org] Sent: Wednesday, September 10, 2008 8:11 AM To: chloe K Cc: nanog at nanog.org Subject: Re: duplicate packet On Wed, 10 Sep 2008, chloe K wrote: > When I ping the ip, I get the duplicate > > I check the ip is just one. Why it happens? > > 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.344 ms > 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.401 ms (DUP!) Not enough information has been given. Just hope it's not being caused by a Level3/Sprint circuit...ours is still doing this (when I change back to HDLC) and they just don't freaking care. Sometimes I wish I worked for a big telco so I could leave things broken and say "hey, I'm the telco, I don't have to care." Maybe we should refuse to pay for the affected DS3 and see if that gets more attention. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ ------------------------------ Message: 6 Date: Wed, 10 Sep 2008 08:10:20 -0500 From: "Laurence F. Sheldon, Jr." Subject: Re: duplicate packet Cc: nanog at nanog.org Message-ID: <48C7C73C.7000900 at cox.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sebastian Abt wrote: > * chloe K wrote: >> When I ping the ip, I get the duplicate >> >> 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.344 ms >> 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.401 ms (DUP!) > ^^^^^^^^^^^^ > What's your netmask? Is 192.168.0.95 your net's broadcast address? Ohhh! Nice catch! ------------------------------ Message: 7 Date: Wed, 10 Sep 2008 06:13:18 -0700 From: "Matthew Petach" Subject: Re: Yahoo! mail admins? To: "Paul Kelly :: Blacknight" Cc: "nanog at nanog.org" Message-ID: <63ac96a50809100613k3f9f2499p9270dbc5b7a82533 at mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On 9/10/08, Paul Kelly :: Blacknight wrote: > Hi There, > > Are there any Yahoo! e-mail admins on the list? We're having some issues at times delivering e-mail to yahoo.co.uk and sometimes some of the other yahoo networks. > Probably not--but folks can probably get the message to the right ears. Let me know off list the nature of the issue (layer 3 reachability vs layer 7 application error messages) and I'll see what I can do to get the message to the right recipients. Thanks! Matt > Thanks, > > 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 > > ------------------------------ Message: 8 Date: Wed, 10 Sep 2008 12:35:24 +0000 (GMT) From: hobbit at avian.org (*Hobbit*) Subject: Re: ingress SMTP To: nanog at nanog.org Message-ID: <20080910123524.3D97E7808 at relayer.avian.org> I am completely convinced that abuse@ in most big providers is a black hole with an autoresponder hung off it, and nothing ever gets done with complaints. NO HUMAN ever sees them, and even if they did, most of the humans at these outfits wouldn't recognize a Received: header if it bit them in the ass. I invite and welcome anyone from the "big boyz" I named in the original question -- verizon, comcast, roadrunner, charter, bellsouth/SBC, and now Google -- *especially* Gmail, given that counterproductive "privacy" policy we noted -- to inform me otherwise. _H* ------------------------------ Message: 9 Date: Wed, 10 Sep 2008 07:38:44 -0700 From: Leo Vegoda Subject: New (2-byte) ASN Allocation for RIPE NCC To: Leo Vegoda Message-ID: Content-Type: text/plain; charset="iso-8859-1" -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This is to confirm that the IANA has allocated one 2-byte ASN block to the RIPE NCC: 48128-49151 Assigned by RIPE NCC whois.ripe.net 2008-09-09 A note of the allocation has been made at: http://www.iana.org/assignments/as-numbers/as-numbers.xml http://www.iana.org/assignments/as-numbers/as-numbers.xhtml http://www.iana.org/assignments/as-numbers/as-numbers.txt Thank you and best regards, Leo Vegoda leo.vegoda at icann.org ******************************************* Internet Assigned Numbers Authority (IANA) 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 Phone: +1-310-823-9358 Fax: +1-310-823-8649 ******************************************* -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFIx9suvBLymJnAzRwRAgnkAKDDxJCilYy0aErDQtQQFEcsCKG/QwCgi+Ao 029EI3Ful4LKPXMJEUGKs3g= =7EeD -----END PGP SIGNATURE----- ------------------------------ Message: 10 Date: Wed, 10 Sep 2008 12:47:26 -0700 From: Jo Rhett Subject: Teleglobe appears to be spam-source zombie network? To: nanog Message-ID: <03F411FC-74D6-48CA-84FC-16706B05BADE at netconsonance.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes We started getting a flood of autobot spam to our listed abuse mailbox about an hour ago out of Teleglobe. Trying to find someone to shut this down has found that 1. Teleglobe has no listed abuse contacts for any of their netblocks 2. The few of their records which have listed e-mail addresses all bounce 3. All listed phone numbers on any netblocks we can find are invalid Any chance that RIPE is more strigent than ARIN and would pull their netblocks until they fix this stuff? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ------------------------------ Message: 11 Date: Wed, 10 Sep 2008 20:51:09 +0100 (WEST) From: Nuno Vieira - nfsi telecom Subject: Re: Teleglobe appears to be spam-source zombie network? To: Jo Rhett Cc: nanog Message-ID: <823080104.21701221076269458.JavaMail.root at zimbra.nfsi.pt> Content-Type: text/plain; charset=utf-8 Try reach them at CAbuse at tatacommunications.com cheers, --- Nuno Vieira nfsi telecom, lda. nuno.vieira at nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ ----- "Jo Rhett" wrote: > We started getting a flood of autobot spam to our listed abuse mailbox > > about an hour ago out of Teleglobe. Trying to find someone to shut > this down has found that > > 1. Teleglobe has no listed abuse contacts for any of their netblocks > 2. The few of their records which have listed e-mail addresses all > bounce > 3. All listed phone numbers on any netblocks we can find are invalid > > Any chance that RIPE is more strigent than ARIN and would pull their > > netblocks until they fix this stuff? > > -- > Jo Rhett > Net Consonance : consonant endings by net philanthropy, open source > and other randomness ------------------------------ Message: 12 Date: Wed, 10 Sep 2008 15:59:35 -0400 From: Marshall Eubanks Subject: Re: Teleglobe appears to be spam-source zombie network? To: Nuno Vieira - nfsi telecom Cc: nanog Message-ID: <0B1059FF-6187-4212-A666-3124BFB38E88 at multicasttech.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes On Sep 10, 2008, at 3:51 PM, Nuno Vieira - nfsi telecom wrote: > Try reach them at CAbuse at tatacommunications.com > Yes - all my teleglobe contacts went over to Tata email addresses during the summer. Regards Marshall > cheers, > --- > Nuno Vieira > nfsi telecom, lda. > > nuno.vieira at nfsi.pt > Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 > http://www.nfsi.pt/ > > > > ----- "Jo Rhett" wrote: > >> We started getting a flood of autobot spam to our listed abuse >> mailbox >> >> about an hour ago out of Teleglobe. Trying to find someone to shut >> this down has found that >> >> 1. Teleglobe has no listed abuse contacts for any of their netblocks >> 2. The few of their records which have listed e-mail addresses all >> bounce >> 3. All listed phone numbers on any netblocks we can find are invalid >> >> Any chance that RIPE is more strigent than ARIN and would pull their >> >> netblocks until they fix this stuff? >> >> -- >> Jo Rhett >> Net Consonance : consonant endings by net philanthropy, open source >> and other randomness > ------------------------------ _______________________________________________ NANOG mailing list NANOG at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog End of NANOG Digest, Vol 8, Issue 38 ************************************ From randy at psg.com Wed Sep 10 16:45:10 2008 From: randy at psg.com (Randy Bush) Date: Thu, 11 Sep 2008 06:45:10 +0900 Subject: Teleglobe appears to be spam-source zombie network? In-Reply-To: <03F411FC-74D6-48CA-84FC-16706B05BADE@netconsonance.com> References: <03F411FC-74D6-48CA-84FC-16706B05BADE@netconsonance.com> Message-ID: <48C83FE6.4030609@psg.com> Jo Rhett wrote: > We started getting a flood of autobot spam to our listed abuse mailbox > about an hour ago out of Teleglobe. Trying to find someone to shut this > down has found that > > 1. Teleglobe has no listed abuse contacts for any of their netblocks > 2. The few of their records which have listed e-mail addresses all bounce > 3. All listed phone numbers on any netblocks we can find are invalid > > Any chance that RIPE is more strigent than ARIN and would pull their > netblocks until they fix this stuff? why don't we just have dick cheney bomb them? randy From LarrySheldon at cox.net Wed Sep 10 16:50:00 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Wed, 10 Sep 2008 16:50:00 -0500 Subject: Teleglobe appears to be spam-source zombie network? In-Reply-To: <48C83FE6.4030609@psg.com> References: <03F411FC-74D6-48CA-84FC-16706B05BADE@netconsonance.com> <48C83FE6.4030609@psg.com> Message-ID: <48C84108.6080907@cox.net> Randy Bush wrote: > Jo Rhett wrote: >> We started getting a flood of autobot spam to our listed abuse mailbox >> about an hour ago out of Teleglobe. Trying to find someone to shut this >> down has found that >> >> 1. Teleglobe has no listed abuse contacts for any of their netblocks >> 2. The few of their records which have listed e-mail addresses all bounce >> 3. All listed phone numbers on any netblocks we can find are invalid >> >> Any chance that RIPE is more strigent than ARIN and would pull their >> netblocks until they fix this stuff? > > why don't we just have dick cheney bomb them? Obama seems to be tyhe one bombing now. From jules.rogers at gmail.com Wed Sep 10 16:51:53 2008 From: jules.rogers at gmail.com (Jules Rogers) Date: Wed, 10 Sep 2008 16:51:53 -0500 Subject: Teleglobe appears to be spam-source zombie network? In-Reply-To: <48C83FE6.4030609@psg.com> References: <03F411FC-74D6-48CA-84FC-16706B05BADE@netconsonance.com> <48C83FE6.4030609@psg.com> Message-ID: <89e9216c0809101451p116e73fbu5a4a632dbcc153d7@mail.gmail.com> Because they don't have oil. On 9/10/08, Randy Bush wrote: > Jo Rhett wrote: >> We started getting a flood of autobot spam to our listed abuse mailbox >> about an hour ago out of Teleglobe. Trying to find someone to shut this >> down has found that >> >> 1. Teleglobe has no listed abuse contacts for any of their netblocks >> 2. The few of their records which have listed e-mail addresses all bounce >> 3. All listed phone numbers on any netblocks we can find are invalid >> >> Any chance that RIPE is more strigent than ARIN and would pull their >> netblocks until they fix this stuff? > > why don't we just have dick cheney bomb them? > > randy > > -- Jules Rogers From joelja at bogus.com Wed Sep 10 19:20:58 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 10 Sep 2008 17:20:58 -0700 Subject: ingress SMTP In-Reply-To: <20080903190015.GS8979@cgi.jachomes.com> References: <20080903151617.A14277808@relayer.avian.org> <48BEB3C3.1070600@gravityfree.com> <20080903161400.GI8979@cgi.jachomes.com> <48BEBDF4.9040109@mtcc.com> <20080903164941.GL8979@cgi.jachomes.com> <20080903190015.GS8979@cgi.jachomes.com> Message-ID: <48C8646A.3040207@bogus.com> Jay R. Ashworth wrote: > On Wed, Sep 03, 2008 at 12:58:53PM -0400, Nicholas Suan wrote: >> On Sep 3, 2008, at 12:49 PM, Jay R. Ashworth wrote: >>> You're forgetting that 587 *is authenticated, always*. >> I'm not sure how that makes much of a difference since the usual spam >> vector is malware that has (almost) complete control of the machine >> in the first place. > > Well, that depends on MUA design, of course, but it's just been pointed > out to me that the RFC says MAY, not MUST. > > Oops. > > Does anyone bother to run an MSA on 587 and *not* require authentication? All my normal relay or lack thereof and delivery rules are in place on my 587 port. Of course muas's and mtas will also do tls as well as authentication over port 25 where available. I don't sea any reason to preclude a host that would be allowed to relay via 25 to do so via 587... Congruent policy makes administration simpler. > Cheers, > -- jra From morrowc.lists at gmail.com Wed Sep 10 20:23:27 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 10 Sep 2008 21:23:27 -0400 Subject: Teleglobe appears to be spam-source zombie network? In-Reply-To: <03F411FC-74D6-48CA-84FC-16706B05BADE@netconsonance.com> References: <03F411FC-74D6-48CA-84FC-16706B05BADE@netconsonance.com> Message-ID: <75cb24520809101823x7fd0304cr644f1193d67439b8@mail.gmail.com> On 9/10/08, Jo Rhett wrote: > We started getting a flood of autobot spam to our listed abuse mailbox about > an hour ago out of Teleglobe. Trying to find someone to shut this down has > found that > > 1. Teleglobe has no listed abuse contacts for any of their netblocks > 2. The few of their records which have listed e-mail addresses all bounce > 3. All listed phone numbers on any netblocks we can find are invalid > > Any chance that RIPE is more strigent than ARIN and would pull their > netblocks until they fix this stuff? It's possible that in the shuffle of company renaming/rebranding/rejiggering-of-people they lost this bit in the shuffle. There's at least one TATA eng person on-list though who may be able to get you a status on the situation. -Chris From yb at rag.byzant.net Wed Sep 10 20:50:21 2008 From: yb at rag.byzant.net (Yann Berthier) Date: Thu, 11 Sep 2008 03:50:21 +0200 Subject: Teleglobe appears to be spam-source zombie network? In-Reply-To: <75cb24520809101823x7fd0304cr644f1193d67439b8@mail.gmail.com> References: <03F411FC-74D6-48CA-84FC-16706B05BADE@netconsonance.com> <75cb24520809101823x7fd0304cr644f1193d67439b8@mail.gmail.com> Message-ID: <20080911015021.GE84103@bashibuzuk.net> On Wed, 10 Sep 2008, at 21:23, Christopher Morrow wrote: > On 9/10/08, Jo Rhett wrote: > > We started getting a flood of autobot spam to our listed abuse mailbox about > > an hour ago out of Teleglobe. Trying to find someone to shut this down has > > found that > > > > 1. Teleglobe has no listed abuse contacts for any of their netblocks > > 2. The few of their records which have listed e-mail addresses all bounce > > 3. All listed phone numbers on any netblocks we can find are invalid > > > > Any chance that RIPE is more strigent than ARIN and would pull their > > netblocks until they fix this stuff? > > It's possible that in the shuffle of company > renaming/rebranding/rejiggering-of-people they lost this bit in the > shuffle. There's at least one TATA eng person on-list though who may > be able to get you a status on the situation. while this is not me you were refering to, i contacted privately Jo on this matter - a customer, probably upset, decided to fire-up a batch of misguided spam reports while there is certainly outdated abuse info for some of our blocks, in this particular case the subnet that was allocated to us has up-to-date mail+phone info and thanks to some posters further up the thread: the abuse mailbox is indeed cabuse at tatacommunications.com From jrhett at netconsonance.com Thu Sep 11 02:16:49 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 11 Sep 2008 00:16:49 -0700 Subject: Teleglobe appears to be spam-source zombie network? In-Reply-To: <20080911015021.GE84103@bashibuzuk.net> References: <03F411FC-74D6-48CA-84FC-16706B05BADE@netconsonance.com> <75cb24520809101823x7fd0304cr644f1193d67439b8@mail.gmail.com> <20080911015021.GE84103@bashibuzuk.net> Message-ID: <554E4AFD-10F7-4F91-91A6-DA8293279A01@netconsonance.com> On Sep 10, 2008, at 6:50 PM, Yann Berthier wrote: > while there is certainly outdated abuse info for some of our blocks, > in this particular case the subnet that was allocated to us has > up-to-date mail+phone info I'd like to note for anyone else who might make similar mistakes -- putting valid contact info only in the top level allocation and not tied to your organization means that nobody can find it, unless they are bored and feel like trying the IP with /25, /24, /23, /22 ... etc until they find your working contact info. Do it right, tie the abuse contact to the organization. It will show up on *all* allocations. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Thu Sep 11 02:18:47 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 11 Sep 2008 00:18:47 -0700 Subject: Teleglobe appears to be spam-source zombie network? In-Reply-To: <75cb24520809101823x7fd0304cr644f1193d67439b8@mail.gmail.com> References: <03F411FC-74D6-48CA-84FC-16706B05BADE@netconsonance.com> <75cb24520809101823x7fd0304cr644f1193d67439b8@mail.gmail.com> Message-ID: On Sep 10, 2008, at 6:23 PM, Christopher Morrow wrote: > It's possible that in the shuffle of company > renaming/rebranding/rejiggering-of-people they lost this bit in the Is it just me, or isn't keeping valid contact information on your netblocks like, a serious affair? Something you should get around to within a few hours, nevermind a few months since the changes? I mean seriously. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From brandon.galbraith at gmail.com Thu Sep 11 02:23:09 2008 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Thu, 11 Sep 2008 02:23:09 -0500 Subject: Teleglobe appears to be spam-source zombie network? In-Reply-To: References: <03F411FC-74D6-48CA-84FC-16706B05BADE@netconsonance.com> <75cb24520809101823x7fd0304cr644f1193d67439b8@mail.gmail.com> Message-ID: <366100670809110023h310d6bb6ge3bdae9ac1d82d18@mail.gmail.com> On 9/11/08, Jo Rhett wrote: > > On Sep 10, 2008, at 6:23 PM, Christopher Morrow wrote: > >> It's possible that in the shuffle of company >> renaming/rebranding/rejiggering-of-people they lost this bit in the >> > > Is it just me, or isn't keeping valid contact information on your netblocks > like, a serious affair? Something you should get around to within a few > hours, nevermind a few months since the changes? > > I mean seriously. Depends on if you take it seriously to begin with, as well as if the next person after you leave takes it seriously. I left an org over a year and a half ago, and the abuse/tech contact info for the netblocks has yet to be updated. YMMV. -brandon From jrhett at netconsonance.com Thu Sep 11 02:28:25 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 11 Sep 2008 00:28:25 -0700 Subject: an effect of ignoring BCP38 In-Reply-To: <20080906134905.GA75970@rommie.caida.org> References: <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> <3861BD57-759F-4EE5-A274-DBCDE7F7485B@ianai.net> <20080905052227.GA8309@vacation.karoshi.com.> <20080906134905.GA75970@rommie.caida.org> Message-ID: <583E77EF-143B-46A3-B488-F44DB97E2340@netconsonance.com> On Sep 6, 2008, at 6:49 AM, k claffy wrote: > do that many networks really allow spoofing? i used > to think so, based on hearsay, but rob beverly's > http://spoofer.csail.mit.edu/summary.php suggests > things are a lot better than they used to be, arbor's > last survey echos same. are rob's numbers inconsistent > with numbers anyone else believes to be true? I hate to spoil anyone's fantasies about this topic, but yeah. Nearly everyone does. I've been in, near, or directly in touch with enough big provider NOCs in the last year on various DoS attach research issues, and nearly nobody... that's right NONE of them were using BCP38 consistently. Name the five biggest providers you can think of. They ain't doing it. Now name the five best transit providers you can think of. They ain't doing it either. (note that all of these claimed to be doing so in that survey, but during attack research they admitted that it was only in small deployments) If someone told me (truthfully) that there was 10% BCP38 compliance out there, I'd be surprised given what I have observed. We don't have a long ways to finish. We have a long ways to start. Finishing isn't even within the horizon yet. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Thu Sep 11 02:32:28 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 11 Sep 2008 00:32:28 -0700 Subject: BCP38 dismissal In-Reply-To: References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> <315BC48A-E42A-48B5-84F6-664395D95A46@netconsonance.com> <8A5FEE72-B8FC-4B42-B8BA-80F170741595@netconsonance.com> Message-ID: On Sep 4, 2008, at 3:22 PM, Gadi Evron wrote: >> On that you'll have to speak for yourself. We have it on every >> customer port ;-) > > Now that is interesting. Can you share a bit about you > rimplementation hardships, costs, customer complaints, etc? One customer complaint. Found the customer was looping traffic between two uplinks and helped them fix the problem ;-) Implementation cost: time/labor to implement automatic management of ACLs on the customer ports. Not all that much cost, since we had already developed infrastructure to do the same thing for customer configurations. Maybe 12 hours of my time coding and testing. Honestly, I expected a lot more problems than we've had. Especially given the fallout I'd seen on the networks trying to do it with Cisco. But the Force10 gear didn't even notice the effect, and it's been ~2 years since I've even thought much about it. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Thu Sep 11 02:40:01 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 11 Sep 2008 00:40:01 -0700 Subject: Force10 Gear - Opinions In-Reply-To: <620fd17c0809051237u2da20972u5ac2015c69101ca3@mail.gmail.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <932F4ABF-B1B4-46FF-8155-E799044E3697@netconsonance.com> <620fd17c0809041007i6d494637tf9017377370cac68@mail.gmail.com> <9DEC696A-A850-46DE-BBB9-13E6C8B4CBAE@netconsonance.com> <620fd17c0809051237u2da20972u5ac2015c69101ca3@mail.gmail.com> Message-ID: <2E59686D-E4E8-44B4-9334-389F2F1D4A85@netconsonance.com> On Sep 5, 2008, at 12:37 PM, Paul Wall wrote: > Jo Rhett wrote: >> Note the "not random" comment. People love to use the random >> feature of ixia/etc but it rarely displays >> actual performance in a production network. > > Once upon a time, vendors released products which relied on CPU-based > "flow" setup. Certain vintages of Cisco, Extreme, Foundry, > Riverstone, etc come to mind. These could forward at "line rate" > under normal conditions. Sufficient randomization on the sources > and/or destinations (DDoS, Windows worm, portscans, ...) and they'd > die a spectacular death. Nowadays, this is less of a concern, as the ... > Either way, I think it's a good test metric. I'd be interested in > hearing of why you think that's not the case. Back on topic, doing a Yes. And those problems were fixed in most gear. What I found *also* was that the flow tables tended to fill up, and a lot of gear thrashes on the flow tables. You need real bi-directional sessions to create the effect properly in many cases. (ie Extreme, which handles random fine but bidirectional flows proved that too much of the work was being done in software) >> I have a current spreadsheet here, and trust me your math went wrong >> somewhere. A completely full chassis is only a bit more than what >> you are >> ... >> But no, I'm not going to redo the math. I'm not a F10 salesperson >> and I >> have much more important things to do right now. > > I'd be interested in seeing where I went "wrong", in the interest of > setting the record straight. The original poster was interested in > how Force 10 stacks up against the competition from a feature and > price prospective. He deserves some cold science, and I'm trying to > help him out. I meant what I said, and I wasn't trying to be rude. There are F10 people on this mailing list, it would serve you to engage them instead of me. I'm quite happy with my Force10 units but I'm not making any commission selling them and I have too much to do to be doing someone else's job. > To wit, you said F10 is cheaper than a comparable Cisco 6500 (in a > basic gig-e configuration). I demonstrated that's not the case. You > responded with ad-hominem attacks, followed by indifference, and > later, claims of emotional distress; still you refuse to provide any > hard numbers, claiming it's "not your job". Where I come from, people > like that are referred to as sore losers. :) You're reading a lot more into it than I bothered to think about it. I've done the math repeatedly, and Force10 always comes out cheaper than Cisco in that scale of port density. Your numbers looked off to me, but letting you know the previous sentence is about all the time I can spend on this topic. Can we kill this now? Thanks. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Thu Sep 11 02:43:20 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 11 Sep 2008 00:43:20 -0700 Subject: Cisco uRPF failures In-Reply-To: <2e9d8ae50809061020x24bdfbf0x3ddcfe3ed8518df2@mail.gmail.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <00c401c9072b$f46a38c0$dd3eaa40$@com> <007401c90e25$6eaf2280$4c0d6780$@com> <6bb5f5b10809031906m67c18854nb4fe7260ad3e153@mail.gmail.com> <5188BB8F-8EFC-4FCA-BA9F-E36E6C3CEB81@netconsonance.com> <2e9d8ae50809061020x24bdfbf0x3ddcfe3ed8518df2@mail.gmail.com> Message-ID: <263B73DE-D014-44E3-9B07-4143FD36D5D0@netconsonance.com> On Sep 6, 2008, at 10:20 AM, Anton Kapela wrote: > On Thu, Sep 4, 2008 at 11:35 AM, Jo Rhett > wrote: > >> That's the surprising thing -- no scenario. Very basic >> configuration. >> Enabling uRPF and then hitting it with a few gig of non-routable >> packets >> consistently caused the sup module to stop talking on the console, >> and > > What do you mean by 'non routable?' Should have been dropped by UDP. > What was the src/dst makeup of the test traffic? Both random sources and singular sources demonstrated the problem. > What version of code? Also, port-channel/lag or ECMP? I don't have those details handy now, nor am I likely to anytime soon. If they've been solved in recent code, great. But I've seen nothing in the tech notes. >> quickly, but that turns out not to be the case. To this day I've >> never > > I've never seen the issues you speak of, so it could be > code/platform/config specific. > > Also, what sup were you testing? 720s, as said repeatedly. > Forgive me, but what does bits/sec have to do with anything? The problem only appeared at high bits/sec, as I've said repeatedly. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Thu Sep 11 02:47:05 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 11 Sep 2008 00:47:05 -0700 Subject: BCP38 dismissal In-Reply-To: <48C3803D.3070402@psg.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> <48C3803D.3070402@psg.com> Message-ID: <87258A0D-135D-4A6E-B0B4-A60B160B3C3A@netconsonance.com> On Sep 7, 2008, at 12:18 AM, Randy Bush wrote: > normally i would have just hit delete. but your ad hominem attack on > the messenger need a response. > > the reality of life is that he is correct in that "attack traffic > comes > from legitimate IP sources anyway." > > therefore, your first duty should be to keep your hosts from joining > the > massive army of botnets. Having no hosts, I can't do much about that other than use various good best practices (including BCP38), run ids units looking for compromised hosts, and respond quickly to each abuse report if my IDS doesn't observe it first. Given that I know of no provider larger than us using BCP38 on every port, and no other provider larger than us that responds to every abuse report, it would appear that we are top of the class in that aspect. Therefore, when someone says "I don't need to do BCP38" because BCP38 doesn't cause problems for them, I consider them a jerk. And yeah, I feel pretty confident looking down my nose at someone like that. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From randy at psg.com Thu Sep 11 02:50:13 2008 From: randy at psg.com (Randy Bush) Date: Thu, 11 Sep 2008 16:50:13 +0900 Subject: BCP38 dismissal In-Reply-To: <87258A0D-135D-4A6E-B0B4-A60B160B3C3A@netconsonance.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> <48C3803D.3070402@psg.com> <87258A0D-135D-4A6E-B0B4-A60B160B3C3A@netconsonance.com> Message-ID: <48C8CDB5.7050004@psg.com> >> normally i would have just hit delete. but your ad hominem attack on >> the messenger need a response. >> >> the reality of life is that he is correct in that "attack traffic comes >> from legitimate IP sources anyway." >> >> therefore, your first duty should be to keep your hosts from joining the >> massive army of botnets. > > Having no hosts, I can't do much about that other than ... i suggest you go back to the mail to which you responded obscenely vilifying the poster who was specifically saying he worried about his host before bcp38. that was specifically the subject. > Given that I know of no provider larger than us using BCP38 on every > port well, that sets an upper bound on the extent of your knowledge, eh. and not a very high one. randy From jrhett at netconsonance.com Thu Sep 11 02:50:29 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 11 Sep 2008 00:50:29 -0700 Subject: Cisco uRPF failures In-Reply-To: <20080908085510.GA27179@mx.ytti.net> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <00c401c9072b$f46a38c0$dd3eaa40$@com> <007401c90e25$6eaf2280$4c0d6780$@com> <6bb5f5b10809031906m67c18854nb4fe7260ad3e153@mail.gmail.com> <5188BB8F-8EFC-4FCA-BA9F-E36E6C3CEB81@netconsonance.com> <20080908085510.GA27179@mx.ytti.net> Message-ID: On Sep 8, 2008, at 1:55 AM, Saku Ytti wrote: > To this day I've never met network operator not using uRPF on Cisco > gear. > (note: network operator. It's probably not used widely by enterprises) As someone who does a lot of work talking to NOCs trying to chase down attack sources, I can honestly tell you that I haven't talked to a single NOC in the last 16 months who had BCP38 on every port, or even on most of their ports. And the majority response is "our (vendor) gear can't handle it". As we both know, Cisco is the largest by far vendor in the marketplace, and I've heard that name more than 70% of the time. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Thu Sep 11 02:55:21 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 11 Sep 2008 00:55:21 -0700 Subject: BCP38 dismissal In-Reply-To: <48C8CDB5.7050004@psg.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> <48C3803D.3070402@psg.com> <87258A0D-135D-4A6E-B0B4-A60B160B3C3A@netconsonance.com> <48C8CDB5.7050004@psg.com> Message-ID: <6FF6EC50-9B1E-4388-B2F1-7C0A6B33CAEE@netconsonance.com> On Sep 11, 2008, at 12:50 AM, Randy Bush wrote: >> Having no hosts, I can't do much about that other than ... > > i suggest you go back to the mail to which you responded obscenely > vilifying the poster who was specifically saying he worried about his > host before bcp38. that was specifically the subject. "host" in that context was his router, which makes your comment make less sense. (having never seen a big iron router become a client in a botnet, myself) He was talking about big iron control plane policy controls. You must have missed the context. >> Given that I know of no provider larger than us using BCP38 on every >> port > > well, that sets an upper bound on the extent of your knowledge, eh. > and > not a very high one. I just had a deep discussion with Verio about this very problem in their network last week. Verio claims no timetable for consistent BCP38 deployment. You want to stop being rude, and start making positive assertations about things you know? I'd love to be wrong, but I've got a whole lot of experience on this topic. If you know better, educate the rest of us. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From pekkas at netcore.fi Thu Sep 11 02:59:50 2008 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 11 Sep 2008 10:59:50 +0300 (EEST) Subject: an effect of ignoring BCP38 In-Reply-To: <583E77EF-143B-46A3-B488-F44DB97E2340@netconsonance.com> References: <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> <3861BD57-759F-4EE5-A274-DBCDE7F7485B@ianai.net> <20080905052227.GA8309@vacation.karoshi.com.> <20080906134905.GA75970@rommie.caida.org> <583E77EF-143B-46A3-B488-F44DB97E2340@netconsonance.com> Message-ID: On Thu, 11 Sep 2008, Jo Rhett wrote: > I've been in, near, or directly in touch with enough big provider NOCs in the > last year on various DoS attach research issues, and nearly nobody... that's > right NONE of them were using BCP38 consistently. Name the five biggest > providers you can think of. They ain't doing it. Now name the five best > transit providers you can think of. They ain't doing it either. (note that > all of these claimed to be doing so in that survey, but during attack > research they admitted that it was only in small deployments) > > If someone told me (truthfully) that there was 10% BCP38 compliance out > there, I'd be surprised given what I have observed. A problem I have with these discussions is that everyone has their own idea what "BCP38" implies. Others say their loose-mode uRPF setups are "BCP38". Others are using strict uRPF or similar (e.g. acls). Some think that Tier1 transit operators should apply one of the options above to their tier2 customers. Others think it should just be applied at the site-edges. Some don't consider spoofing protection at LAN interface level at all, others call that also BCP38. Etc. Your note above seems to imply that you would expect the five best transit providers you think of to apply BCP38 (strict?) to their customers. Even if the customer is a major ISP? (However, if your argument is about a smallish end-site, I'd agree spoofing protection should be applied there.) FWIW, I've tested what would happen if I were to enable strict-mode (feasible paths) uRPF on an Internet exchange (all peerings). If I recall correctly, the amount of dropped packets would have been in the order of 1%. We decided not to do it. Maybe those "five biggest providers you can think of" have similar experiences with their biggest customers? Loose mode URPF is seems (IMHO) pretty much waste of time and is confusing the discussion about real spoofing protection. The added protection compared to ACLs that drop private and possibly bogons is not that big and it causes transient losses when the routing tables are changing. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From jrhett at netconsonance.com Thu Sep 11 03:07:52 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 11 Sep 2008 01:07:52 -0700 Subject: an effect of ignoring BCP38 In-Reply-To: References: <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> <3861BD57-759F-4EE5-A274-DBCDE7F7485B@ianai.net> <20080905052227.GA8309@vacation.karoshi.com.> <20080906134905.GA75970@rommie.caida.org> <583E77EF-143B-46A3-B488-F44DB97E2340@netconsonance.com> Message-ID: <50C358B1-45AB-487E-A628-62230FD0E537@netconsonance.com> On Sep 11, 2008, at 12:59 AM, Pekka Savola wrote: > A problem I have with these discussions is that everyone has their > own idea what "BCP38" implies. Others say their loose-mode uRPF > setups are "BCP38". Others are using strict uRPF or similar (e.g. > acls). Some think that Tier1 transit operators should apply one of > the options above to their tier2 customers. Others think it should > just be applied at the site-edges. Some don't consider spoofing > protection at LAN interface level at all, others call that also > BCP38. Etc. Honestly, *anything* is better than most of what's out there, which is *nothing*. > Loose mode URPF is seems (IMHO) pretty much waste of time and is > confusing the discussion about real spoofing protection. The added > protection compared to ACLs that drop private and possibly bogons is > not that big and it causes transient losses when the routing tables > are changing. I disagree. But I will say that if everyone would apply strict mode or ACLs to their end point interfaces, this would likely make most of the loose mode irrelevant. And your arguments about BGP changes affecting loose mode are only problematic on the busiest peering ports. Loose mode works perfectly fine with zero drops (even on Cisco) on anything smaller than a full feed (ie, that ISP client of yours you do BGP with) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From eugen at imacandi.net Thu Sep 11 04:58:47 2008 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Thu, 11 Sep 2008 12:58:47 +0300 Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: References: <20080908112049.256D9BBE@resin13.mta.everyone.net> Message-ID: <48C8EBD7.9000605@imacandi.net> Gadi Evron wrote: > On Mon, 8 Sep 2008, Scott Weeks wrote: >> >> >> --- jpleger at gmail.com wrote: >> I am sure if I looked into it more I could find some exploits related >> to the sites. >> ------------------------------------- >> >> >> "Why software piracy might actually be good for companies." >> >> Folks should clean their own house before pointing fingers at others... > > My house may not be clean right now, but the cleaner is coming > tomorrow. However, filth from their house is making my house smell. I > am very happy they are willing to clean up, but it still smells for > some reason. > > Enough with analogies, you are making this discussion into a hostile > environment for them to reply in. > > What are you afraid of, anyway? Are you running a bullet-proof hosting > farm? Why should an ISP provide proof of the good behavior of their clients ? Or in your conuntry you're considered guilty until proven otherwise ? From ktho at cabletv.com.hk Thu Sep 11 05:14:59 2008 From: ktho at cabletv.com.hk (Ho Kin Tak (BNEO)) Date: Thu, 11 Sep 2008 18:14:59 +0800 Subject: 1Gbps 120km or 150km sfp gbic In-Reply-To: Message-ID: <78CDD5837BDAAB44B33AF00D7DFE353F0125346F@MAILSVR.catvmail.local> Hi There, Did anyone use 1Gbps 120km and 150km sfp on the Cisco switch? Does it work? What is the max. dB loss for the sfp? Thanks, Tak From list-nanog at pwns.ms Thu Sep 11 05:23:29 2008 From: list-nanog at pwns.ms (list-nanog at pwns.ms) Date: Thu, 11 Sep 2008 10:23:29 +0000 Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: <48C8EBD7.9000605@imacandi.net> References: <20080908112049.256D9BBE@resin13.mta.everyone.net> <48C8EBD7.9000605@imacandi.net> Message-ID: <20080911102329.GA8928@pwns.ms> > Why should an ISP provide proof of the good behavior of their clients ? > Or in your conuntry you're considered guilty until proven otherwise ? This is not a court. In court, if you are determined guilty a large punishment may be exacted (note: it's innocent until determined to be very likely guilty in criminal cases, innocent until probably guilty in civil cases); here, that is not the case. They have a history of abuse; it's fair to be suspicious of them (why did they let the abuse last so long?) and ask for an example of a legitimate client. If they have a few, it should be easy to find one willing to be used as an example. From tim at pelican.org Thu Sep 11 05:31:51 2008 From: tim at pelican.org (Tim Franklin) Date: Thu, 11 Sep 2008 11:31:51 +0100 (BST) Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: <48C8EBD7.9000605@imacandi.net> References: <20080908112049.256D9BBE@resin13.mta.everyone.net> <48C8EBD7.9000605@imacandi.net> Message-ID: <1709b5ab4cd938f196fce420ee8591f8.squirrel@webmail.pelican.org> On Thu, September 11, 2008 10:58 am, Eugeniu Patrascu wrote: > Why should an ISP provide proof of the good behavior of their clients ? > Or in your conuntry you're considered guilty until proven otherwise ? Conversely, and sticking close to the 'clean house' metaphor, if someone has a history of tramping mud into your carpets every previous time they've visited, is it unreasonable to ask them to present clean shoes before letting them into your house again? Regards, Tim. From rs at seastrom.com Thu Sep 11 07:02:32 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Thu, 11 Sep 2008 08:02:32 -0400 Subject: ingress SMTP In-Reply-To: <48C8646A.3040207@bogus.com> (Joel Jaeggli's message of "Wed, 10 Sep 2008 17:20:58 -0700") References: <20080903151617.A14277808@relayer.avian.org> <48BEB3C3.1070600@gravityfree.com> <20080903161400.GI8979@cgi.jachomes.com> <48BEBDF4.9040109@mtcc.com> <20080903164941.GL8979@cgi.jachomes.com> <20080903190015.GS8979@cgi.jachomes.com> <48C8646A.3040207@bogus.com> Message-ID: <86ljxyj3fr.fsf@seastrom.com> Joel Jaeggli writes: >> Does anyone bother to run an MSA on 587 and *not* require authentication? > > All my normal relay or lack thereof and delivery rules are in place on > my 587 port. Of course muas's and mtas will also do tls as well as > authentication over port 25 where available. I don't sea any reason to > preclude a host that would be allowed to relay via 25 to do so via 587... > > Congruent policy makes administration simpler. Counterpoint here: I do not allow relaying (only local delivery and maybe MX but I think I'm not doing secondary MX for anyone anymore) over port 25 and I do not allow authentication over port 25 either. Likewise, I do not allow unauthenticated local delivery on port 587, demand STARTTLS on port 587, and generally you have to auth to do anything. The extra effort required to set this up (exim recipes available) pays dividends by ensuring that people have their MUAs configured properly at home - otherwise they won't work at all - and helps avoid whiney long distance phone calls asking for help from some user who's off in Bonaire or something. -r From james at towardex.com Thu Sep 11 07:23:38 2008 From: james at towardex.com (James Jun) Date: Thu, 11 Sep 2008 08:23:38 -0400 Subject: BCP38 dismissal In-Reply-To: <6FF6EC50-9B1E-4388-B2F1-7C0A6B33CAEE@netconsonance.com> References: <4288131ED5E3024C9CD4782CECCAD2C7037AF76B@LMC-MAIL2.exempla.org> <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> <48C3803D.3070402@psg.com> <87258A0D-135D-4A6E-B0B4-A60B160B3C3A@netconsonance.com> <48C8CDB5.7050004@psg.com> <6FF6EC50-9B1E-4388-B2F1-7C0A6B33CAEE@netconsonance.com> Message-ID: <006001c91409$38b75550$aa25fff0$@com> > > i suggest you go back to the mail to which you responded obscenely > > vilifying the poster who was specifically saying he worried about his > > host before bcp38. that was specifically the subject. > > "host" in that context was his router, which makes your comment make > less sense. (having never seen a big iron router become a client in a > botnet, myself) He was talking about big iron control plane policy > controls. You must have missed the context. Actually, Randy is right. We were discussing in context of routers and botnets themselves. "Host" in my context was about the botnets sending attack from legitimate IP sources that BCP38 will not be able to defeat. > You want to stop being rude, and start making positive assertations > about things you know? I'd love to be wrong, but I've got a whole lot > of experience on this topic. If you know better, educate the rest of > us. No, you have demonstrated that the only jerk in this entire forum is no one but you with limited bounds of intelligence. Before you go on and call someone a "jerk", "idiot" and falsely accuse him of ~not wanting to deploy BCP38[1]~, read your own posts and start making positive assertions about things that you know yourself. [1]: Almost every network that I help manage is operated with BCP38 either with uRPF or even with automatic-scripted SAV (source address verification/filtering)/ ACL's. james From justin at justinshore.com Thu Sep 11 07:39:00 2008 From: justin at justinshore.com (Justin Shore) Date: Thu, 11 Sep 2008 07:39:00 -0500 Subject: Teleglobe appears to be spam-source zombie network? In-Reply-To: <48C83FE6.4030609@psg.com> References: <03F411FC-74D6-48CA-84FC-16706B05BADE@netconsonance.com> <48C83FE6.4030609@psg.com> Message-ID: <48C91164.8020002@justinshore.com> Randy Bush wrote: > why don't we just have dick cheney bomb them? We could send in the Trojan Moose. Justin From lowen at pari.edu Thu Sep 11 07:50:24 2008 From: lowen at pari.edu (Lamar Owen) Date: Thu, 11 Sep 2008 08:50:24 -0400 Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: <20080911102329.GA8928@pwns.ms> References: <20080908112049.256D9BBE@resin13.mta.everyone.net> Message-ID: <200809110850.25652.lowen@pari.edu> On Thursday 11 September 2008 06:23:29 list-nanog at pwns.ms wrote: > This is not a court. In court, if you are determined guilty a large > punishment may be exacted Depeering is not a large punishment? In the internet world, mass depeering / de-transitting like we've see in this instance is akin to capital punishment. By vigilantes. The US Old West redux. But even in a court of law in a criminal case a defense must be made, otherwise the least sort of evidence of culpability can produce conviction; the defendant must at least put on a defense to invalidate the culpatory evidence. So when culpatory evidence is presented in these cases, requesting exculpatory evidence is very reasonable. Lack of a defense in a civil case will virtually guarantee a favorable judgment for the plaintiff, however. From karnaugh at karnaugh.za.net Thu Sep 11 08:13:07 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Thu, 11 Sep 2008 15:13:07 +0200 Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: <200809110850.25652.lowen@pari.edu> References: <20080908112049.256D9BBE@resin13.mta.everyone.net> <200809110850.25652.lowen@pari.edu> Message-ID: <48C91963.2060801@karnaugh.za.net> Lamar Owen wrote: > Lack of a defense in a civil case will virtually guarantee a favorable > judgment for the plaintiff, however. > Networks (at least in most countries) are 100% private entities who can de-peer whoever they want for whatever reason they want. From morrowc.lists at gmail.com Thu Sep 11 08:24:22 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 11 Sep 2008 09:24:22 -0400 Subject: Teleglobe appears to be spam-source zombie network? In-Reply-To: References: <03F411FC-74D6-48CA-84FC-16706B05BADE@netconsonance.com> <75cb24520809101823x7fd0304cr644f1193d67439b8@mail.gmail.com> Message-ID: <75cb24520809110624h34d24a57r17174a6170e6db07@mail.gmail.com> On Thu, Sep 11, 2008 at 3:18 AM, Jo Rhett wrote: > On Sep 10, 2008, at 6:23 PM, Christopher Morrow wrote: >> >> It's possible that in the shuffle of company >> renaming/rebranding/rejiggering-of-people they lost this bit in the > > Is it just me, or isn't keeping valid contact information on your netblocks > like, a serious affair? Something you should get around to within a few > hours, nevermind a few months since the changes? > That's not my arguement ;( the thing I noticed while at a telco is that sometimes they don't care about the intertubes :( the corporate masters have other priorities. It sucks, I was thinking that the teleglobe/vsnl/tata folks may have gotten bitten by a similar event. (and yes, having as up-to-date info as possible is important for your customers and your peers) -Chris From pekkas at netcore.fi Thu Sep 11 08:32:57 2008 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 11 Sep 2008 16:32:57 +0300 (EEST) Subject: an effect of ignoring BCP38 In-Reply-To: <50C358B1-45AB-487E-A628-62230FD0E537@netconsonance.com> References: <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> <3861BD57-759F-4EE5-A274-DBCDE7F7485B@ianai.net> <20080905052227.GA8309@vacation.karoshi.com.> <20080906134905.GA75970@rommie.caida.org> <583E77EF-143B-46A3-B488-F44DB97E2340@netconsonance.com> <50C358B1-45AB-487E-A628-62230FD0E537@netconsonance.com> Message-ID: On Thu, 11 Sep 2008, Jo Rhett wrote: >> [Pekka:] >> Loose mode URPF is [..] (IMHO) pretty much waste of time and is confusing >> the discussion about real spoofing protection. The added protection >> compared to ACLs that drop private and possibly bogons is not that big and >> it causes transient losses when the routing tables are changing. > > I disagree. But I will say that if everyone would apply strict mode or ACLs > to their end point interfaces, this would likely make most of the loose mode > irrelevant. FWIW, based on off-list discussion, Jo's disagreement seems to stem from a misunderstanding of how loose uRPF works (he didn't know it accepts any packet that has a route in the routing table). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From jrhett at netconsonance.com Thu Sep 11 11:57:23 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 11 Sep 2008 09:57:23 -0700 Subject: an effect of ignoring BCP38 In-Reply-To: References: <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> <3861BD57-759F-4EE5-A274-DBCDE7F7485B@ianai.net> <20080905052227.GA8309@vacation.karoshi.com.> <20080906134905.GA75970@rommie.caida.org> <583E77EF-143B-46A3-B488-F44DB97E2340@netconsonance.com> <50C358B1-45AB-487E-A628-62230FD0E537@netconsonance.com> Message-ID: <35C93554-180A-4FBA-A92D-1958447B6338@netconsonance.com> On Sep 11, 2008, at 6:32 AM, Pekka Savola wrote: > FWIW, based on off-list discussion, Jo's disagreement seems to stem > from a misunderstanding of how loose uRPF works (he didn't know it > accepts any packet that has a route in the routing table). Um, no. Because if you put loose mode uRPF on your edges you aren't implementing BCP38 now are you? I don't care how it is deployed. That's your job ;-) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From Valdis.Kletnieks at vt.edu Thu Sep 11 12:10:34 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 11 Sep 2008 13:10:34 -0400 Subject: an effect of ignoring BCP38 In-Reply-To: Your message of "Thu, 11 Sep 2008 00:28:25 PDT." <583E77EF-143B-46A3-B488-F44DB97E2340@netconsonance.com> References: <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> <3861BD57-759F-4EE5-A274-DBCDE7F7485B@ianai.net> <20080905052227.GA8309@vacation.karoshi.com> <20080906134905.GA75970@rommie.caida.org> <583E77EF-143B-46A3-B488-F44DB97E2340@netconsonance.com> Message-ID: <21546.1221153034@turing-police.cc.vt.edu> On Thu, 11 Sep 2008 00:28:25 PDT, Jo Rhett said: > I've been in, near, or directly in touch with enough big provider NOCs > in the last year on various DoS attach research issues, and nearly > nobody... that's right NONE of them were using BCP38 consistently. > Name the five biggest providers you can think of. They ain't doing > it. Now name the five best transit providers you can think of. They > ain't doing it either. (note that all of these claimed to be doing so > in that survey, but during attack research they admitted that it was > only in small deployments) Part of the problem is that if you're talking about the 5 biggest providers, and the 5 biggest transit, you're talking about places with routing swamps big enough, and with sufficient dragons in residence, that you really *can't* do BCP38 in any sane manner. AS1312 (us) is able to do very strict BCP38 on a per-port level on every router port, because we *know* what's supposed to be on every subnet. By the time you walk our list of upstreams to any of the '5 biggest anything', you've gotten to places where our multihomed status means you can't filter our source address very easily (or more properly, where you can't filter multihomed sources in general). > If someone told me (truthfully) that there was 10% BCP38 compliance > out there, I'd be surprised given what I have observed. The MIT Spoofer project seems to indicate that closer to 50% *of the edge* is doing sane filtering. And that's where you need to do it - *edge* not *core*. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From saku+nanog at ytti.fi Thu Sep 11 12:11:28 2008 From: saku+nanog at ytti.fi (Saku Ytti) Date: Thu, 11 Sep 2008 20:11:28 +0300 Subject: Cisco uRPF failures In-Reply-To: References: <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <00c401c9072b$f46a38c0$dd3eaa40$@com> <007401c90e25$6eaf2280$4c0d6780$@com> <6bb5f5b10809031906m67c18854nb4fe7260ad3e153@mail.gmail.com> <5188BB8F-8EFC-4FCA-BA9F-E36E6C3CEB81@netconsonance.com> <20080908085510.GA27179@mx.ytti.net> Message-ID: <20080911171128.GA5283@mx.ytti.net> On (2008-09-11 00:50 -0700), Jo Rhett wrote: > As someone who does a lot of work talking to NOCs trying to chase down > attack sources, I can honestly tell you that I haven't talked to a > single NOC in the last 16 months who had BCP38 on every port, or even on > most of their ports. And the majority response is "our (vendor) gear > can't handle it". As we both know, Cisco is the largest by far vendor > in the marketplace, and I've heard that name more than 70% of the time. Sound like these shops are using 3550 as router, which is common for smaller shops, especially in EU. And indeed, 3550 would not do uRPF. (3560E does). -- ++ytti From jrhett at netconsonance.com Thu Sep 11 12:25:01 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 11 Sep 2008 10:25:01 -0700 Subject: an effect of ignoring BCP38 In-Reply-To: <21546.1221153034@turing-police.cc.vt.edu> References: <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> <3861BD57-759F-4EE5-A274-DBCDE7F7485B@ianai.net> <20080905052227.GA8309@vacation.karoshi.com> <20080906134905.GA75970@rommie.caida.org> <583E77EF-143B-46A3-B488-F44DB97E2340@netconsonance.com> <21546.1221153034@turing-police.cc.vt.edu> Message-ID: <96939A91-0239-4670-BF07-7F4D7C114633@netconsonance.com> On Sep 11, 2008, at 10:10 AM, Valdis.Kletnieks at vt.edu wrote: > Part of the problem is that if you're talking about the 5 biggest > providers, > and the 5 biggest transit, you're talking about places with routing > swamps > big enough, and with sufficient dragons in residence, that you > really *can't* > do BCP38 in any sane manner. AS1312 (us) is able to do very strict > BCP38 > on a per-port level on every router port, because we *know* what's > supposed to > be on every subnet. By the time you walk our list of upstreams to > any of > the '5 biggest anything', you've gotten to places where our > multihomed status > means you can't filter our source address very easily (or more > properly, where > you can't filter multihomed sources in general). I don't agree with this statement. I hear this a lot, and it's not really true. Being multihomed doesn't mean that your source addresses are likely to be random. (or would be valid if they were) A significant portion of our customers, and *all* of the biggest paying ones, are multihomed. And they might have a lot of different ranges, but we know what the ranges are and filter on those. > The MIT Spoofer project seems to indicate that closer to 50% *of the > edge* is > doing sane filtering. And that's where you need to do it - *edge* > not *core*. I've said much the same myself. With the caveot that if you aren't doing it at the edge, you need to be doing it at the closest edge you can find. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Thu Sep 11 12:26:54 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 11 Sep 2008 10:26:54 -0700 Subject: Cisco uRPF failures In-Reply-To: <20080911171128.GA5283@mx.ytti.net> References: <620fd17c0808232252o586e79b2t2794df2e0cd0ff2c@mail.gmail.com> <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <00c401c9072b$f46a38c0$dd3eaa40$@com> <007401c90e25$6eaf2280$4c0d6780$@com> <6bb5f5b10809031906m67c18854nb4fe7260ad3e153@mail.gmail.com> <5188BB8F-8EFC-4FCA-BA9F-E36E6C3CEB81@netconsonance.com> <20080908085510.GA27179@mx.ytti.net> <20080911171128.GA5283@mx.ytti.net> Message-ID: On Sep 11, 2008, at 10:11 AM, Saku Ytti wrote: > On (2008-09-11 00:50 -0700), Jo Rhett wrote: >> As someone who does a lot of work talking to NOCs trying to chase >> down >> attack sources, I can honestly tell you that I haven't talked to a >> single NOC in the last 16 months who had BCP38 on every port, or >> even on >> most of their ports. And the majority response is "our (vendor) gear >> can't handle it". As we both know, Cisco is the largest by far >> vendor >> in the marketplace, and I've heard that name more than 70% of the >> time. > > Sound like these shops are using 3550 as router, which is common for > smaller shops, especially in EU. And indeed, 3550 would not do uRPF. > (3560E does). I don't honestly know. I do know that in every case it was mentioned to me it was either a 6500 or a 7600. (that it was a Cisco anyway) But frankly, lack of uRPF doesn't mean that BCP38 is impossible. My generation of Force10 gear can't do uRPF. Yet we are BCP38 compliant. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From pekkas at netcore.fi Thu Sep 11 12:59:39 2008 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 11 Sep 2008 20:59:39 +0300 (EEST) Subject: an effect of ignoring BCP38 In-Reply-To: <96939A91-0239-4670-BF07-7F4D7C114633@netconsonance.com> References: <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> <3861BD57-759F-4EE5-A274-DBCDE7F7485B@ianai.net> <20080905052227.GA8309@vacation.karoshi.com> <20080906134905.GA75970@rommie.caida.org> <583E77EF-143B-46A3-B488-F44DB97E2340@netconsonance.com> <21546.1221153034@turing-police.cc.vt.edu> <96939A91-0239-4670-BF07-7F4D7C114633@netconsonance.com> Message-ID: On Thu, 11 Sep 2008, Jo Rhett wrote: > On Sep 11, 2008, at 10:10 AM, Valdis.Kletnieks at vt.edu wrote: >> By the time you walk our list of upstreams to any of the '5 biggest >> anything', you've gotten to places where our multihomed status >> means you can't filter our source address very easily (or more >> properly, where you can't filter multihomed sources in general). > > I don't agree with this statement. I hear this a lot, and it's not really > true. Being multihomed doesn't mean that your source addresses are likely to > be random. (or would be valid if they were) > > A significant portion of our customers, and *all* of the biggest paying ones, > are multihomed. And they might have a lot of different ranges, but we know > what the ranges are and filter on those. If you can manage ACLs for these customers, that's fine. But maybe your multihomed customers and '5 biggest anything' customers are different. Maybe your multihomed customer has 5 prefixes. The big ones could have 5000. That's a pretty big ACL to manage. This is where Strict URPF (+feasible paths) helps a lot because in some cases you don't need to manage those ACLs by hand. But this gets broken if the customer advertises more specific routes from another provider, but doesn't advertise these to you -- your route to those more specifics goes through another ISP, and if the site is sourcing packets from those more specifics through you, the strict uRPF would drop them. There are ways to work around this, e.g. by requiring that the customers advertise the more specifics to you as well but mark them so that you don't propagate them, but I suspect this is not feasible in the higher tiers of ISP business. http://tools.ietf.org/html/draft-savola-bcp84-urpf-experiences Section 3 discusses this a bit. FWIW: we use feasible-paths strict uRPF on all customer and LAN interface without exception. Multihomed ones as well, though it's a bit more work. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From Valdis.Kletnieks at vt.edu Thu Sep 11 13:07:35 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 11 Sep 2008 14:07:35 -0400 Subject: an effect of ignoring BCP38 In-Reply-To: Your message of "Thu, 11 Sep 2008 10:25:01 PDT." <96939A91-0239-4670-BF07-7F4D7C114633@netconsonance.com> References: <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <620fd17c0808260018i2900ede5j44d0bd2344d68a85@mail.gmail.com> <69927A0C-2DB0-44E0-9B29-1DFF39FE7CDA@netconsonance.com> <620fd17c0809040047k3d2ff053g3f4e9e2e26da76ac@mail.gmail.com> <00d501c90e99$ffb4e480$ff1ead80$@com> <4B934B67-D364-4619-A6CC-7FCDCF3EBFEA@netconsonance.com> <3861BD57-759F-4EE5-A274-DBCDE7F7485B@ianai.net> <20080905052227.GA8309@vacation.karoshi.com> <20080906134905.GA75970@rommie.caida.org> <583E77EF-143B-46A3-B488-F44DB97E2340@netconsonance.com> <21546.1221153034@turing-police.cc.vt.edu> <96939A91-0239-4670-BF07-7F4D7C114633@netconsonance.com> Message-ID: <24293.1221156455@turing-police.cc.vt.edu> On Thu, 11 Sep 2008 10:25:01 PDT, Jo Rhett said: > I don't agree with this statement. I hear this a lot, and it's not > really true. Being multihomed doesn't mean that your source addresses > are likely to be random. (or would be valid if they were) > > A significant portion of our customers, and *all* of the biggest > paying ones, are multihomed. And they might have a lot of different > ranges, but we know what the ranges are and filter on those. The problem isn't your customers, it's *their* customers who also multihome to somebody you peer with at 3 other locations. AS1312 talks to AS7066, which talks to AS1239, and we talk to AS40220, which talks to Level3 and AboveNet. Now - for each of your routers, what interfaces *can* or *can't* see legitimate packets from us? Does your answer change if something at MATP burps and loses its Lambdarail connection? *That* is the use case that makes it difficult-to-impossible for the 'top 5' to do anything resembling strict BCP38. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From oberman at es.net Thu Sep 11 13:24:43 2008 From: oberman at es.net (Kevin Oberman) Date: Thu, 11 Sep 2008 11:24:43 -0700 Subject: an effect of ignoring BCP38 In-Reply-To: Your message of "Thu, 11 Sep 2008 20:59:39 +0300." Message-ID: <20080911182443.635024500F@ptavv.es.net> > Date: Thu, 11 Sep 2008 20:59:39 +0300 (EEST) > From: Pekka Savola > > On Thu, 11 Sep 2008, Jo Rhett wrote: > > On Sep 11, 2008, at 10:10 AM, Valdis.Kletnieks at vt.edu wrote: > >> By the time you walk our list of upstreams to any of the '5 biggest > >> anything', you've gotten to places where our multihomed status > >> means you can't filter our source address very easily (or more > >> properly, where you can't filter multihomed sources in general). > > > > I don't agree with this statement. I hear this a lot, and it's not really > > true. Being multihomed doesn't mean that your source addresses are likely to > > be random. (or would be valid if they were) > > > > A significant portion of our customers, and *all* of the biggest paying ones, > > are multihomed. And they might have a lot of different ranges, but we know > > what the ranges are and filter on those. > > If you can manage ACLs for these customers, that's fine. But maybe > your multihomed customers and '5 biggest anything' customers are > different. Maybe your multihomed customer has 5 prefixes. The big > ones could have 5000. That's a pretty big ACL to manage. It's big, but not un-workable. Just looking at our lists, the longest is over 212K entries and we have 5 over 5K and 20 over 1K. We would have even bigger ones if the IRR had more complete information. I'll admit that doing this for a tier-1 would probably not work, though I have never been able to try as the requisite information is not publicly available. -- 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 Sep 11 15:41:28 2008 From: oberman at es.net (Kevin Oberman) Date: Thu, 11 Sep 2008 13:41:28 -0700 Subject: an effect of ignoring BCP38 In-Reply-To: Your message of "Thu, 11 Sep 2008 11:24:43 PDT." <20080911182443.635024500F@ptavv.es.net> Message-ID: <20080911204128.07BA64501D@ptavv.es.net> > Date: Thu, 11 Sep 2008 11:24:43 -0700 > From: "Kevin Oberman" > > > Date: Thu, 11 Sep 2008 20:59:39 +0300 (EEST) > > From: Pekka Savola > > > > On Thu, 11 Sep 2008, Jo Rhett wrote: > > > On Sep 11, 2008, at 10:10 AM, Valdis.Kletnieks at vt.edu wrote: > > >> By the time you walk our list of upstreams to any of the '5 biggest > > >> anything', you've gotten to places where our multihomed status > > >> means you can't filter our source address very easily (or more > > >> properly, where you can't filter multihomed sources in general). > > > > > > I don't agree with this statement. I hear this a lot, and it's not really > > > true. Being multihomed doesn't mean that your source addresses are likely to > > > be random. (or would be valid if they were) > > > > > > A significant portion of our customers, and *all* of the biggest paying ones, > > > are multihomed. And they might have a lot of different ranges, but we know > > > what the ranges are and filter on those. > > > > If you can manage ACLs for these customers, that's fine. But maybe > > your multihomed customers and '5 biggest anything' customers are > > different. Maybe your multihomed customer has 5 prefixes. The big > > ones could have 5000. That's a pretty big ACL to manage. > > It's big, but not un-workable. Just looking at our lists, the longest is > over 212K entries and we have 5 over 5K and 20 over 1K. We would have > even bigger ones if the IRR had more complete information. Ack! Fat fingered it! Certainly not 212K entries. That was supposed to be 12K. Not nearly so impressive. -- 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 jlloret at dcom.upv.es Thu Sep 11 17:25:43 2008 From: jlloret at dcom.upv.es (Jaime Lloret Mauri) Date: Fri, 12 Sep 2008 00:25:43 +0200 Subject: 2nd CfP: ICNS 2009 | April 21-25, 2009 - Valencia, Spain Message-ID: <1221171943.48c99ae74db98@webmail.upv.es> Please consider to contribute to and/or forward to the appropriate groups the following opportunity to submit and publish original scientific results. Apologies for cross-postings. ============== ICNS 2009 | Call for Papers =============== CALL FOR PAPERS, TUTORIALS, PANELS ICNS 2009, The Fifth International Conference on Networking and Services April 21-25, 2009 - Valencia, Spain General page: http://www.iaria.org/conferences2009/ICNS09.html Call for Papers: http://www.iaria.org/conferences2009/CfPICNS09.html Important deadlines: Submission (full paper) November 1, 2008 Authors notification December 5, 2008 Registration December 20, 2008 Camera ready December 25, 2008 Submissions will be peer-reviewed, published by IEEE CS Press, posted in IEEE Digital Library, and indexed with the major indexes. Extended versions of selected papers will be invited for specialized journals. ICNS 2009 Area Tracks are the following (details in the CfP on site): ENCOT: Emerging Network Communications and Technologies COMAN: Network Control and Management SERVI: Multi-technology service deployment and assurance NGNUS: Next Generation Networks and Ubiquitous Services MPQSI: Multi Provider QoS/SLA Internetworking GRIDNS: Grid Networks and Services EDNA: Emergency Services and Disaster Recovery of Networks and Applications IPv6DFI: Deploying the Future Infrastructure IPDy: Internet Packet Dynamics GOBS: GRID over Optical Burst Switching Networks ================================= ICNS 2009 Chairs: General Chair: Jaime Lloret Mauri, Polytechnic University of Valencia, Spain TPC Chairs: Salvador Sales, Polytechnic University of Valencia, Spain Feng Xia, Queensland University of Technology, Australia / Zhejiang University, China Advisory Board Chair: Petre Dini, Cisco, USA ICNS 2009 Industry Chairs: Kevin Y Ung, Boeing, USA Leo Lehmann, OFCOM, Switzerland ================================ -- From patrick at ianai.net Thu Sep 11 17:37:59 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 11 Sep 2008 18:37:59 -0400 Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: <200809110850.25652.lowen@pari.edu> References: <20080908112049.256D9BBE@resin13.mta.everyone.net> <200809110850.25652.lowen@pari.edu> Message-ID: <5D20455D-01B1-4406-AAEE-FFD9654DDF59@ianai.net> On Sep 11, 2008, at 8:50 AM, Lamar Owen wrote: > On Thursday 11 September 2008 06:23:29 list-nanog at pwns.ms wrote: >> This is not a court. In court, if you are determined guilty a large >> punishment may be exacted > > Depeering is not a large punishment? > > In the internet world, mass depeering / de-transitting like we've > see in this > instance is akin to capital punishment. By vigilantes. The US Old > West > redux. You are confused. Connecting to my network is a PRIVILEGE, not a right. You lose a criminal case, you lose rights (e.g. freedom to walk outside). Disconnecting you from my network is not denying any of your rights. There is no law or even custom stopping me from asking you to prove you are worthy to connect to my network. You don't want to prove it, that's your right, just as it is my right to not connect to you. Mind if I ask why you think you have any right to connect to my network if I do not want you to do so? For _any_ reason, including not showing me "legit" customers, political affiliation, or even the color of your hat? -- TTFN, patrick > But even in a court of law in a criminal case a defense must be made, > otherwise the least sort of evidence of culpability can produce > conviction; > the defendant must at least put on a defense to invalidate the > culpatory > evidence. So when culpatory evidence is presented in these cases, > requesting > exculpatory evidence is very reasonable. > > Lack of a defense in a civil case will virtually guarantee a favorable > judgment for the plaintiff, however. > From randy at psg.com Thu Sep 11 17:52:51 2008 From: randy at psg.com (Randy Bush) Date: Fri, 12 Sep 2008 07:52:51 +0900 Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: <5D20455D-01B1-4406-AAEE-FFD9654DDF59@ianai.net> References: <20080908112049.256D9BBE@resin13.mta.everyone.net> <200809110850.25652.lowen@pari.edu> <5D20455D-01B1-4406-AAEE-FFD9654DDF59@ianai.net> Message-ID: <48C9A143.1080709@psg.com> >> In the internet world, mass depeering / de-transitting like we've >> see in this instance is akin to capital punishment. By vigilantes. >> The US Old West redux. > Connecting to my network is a PRIVILEGE, not a right. You lose a > criminal case, you lose rights (e.g. freedom to walk outside). > Disconnecting you from my network is not denying any of your rights. > > There is no law or even custom stopping me from asking you to prove > you are worthy to connect to my network. You don't want to prove it, > that's your right, just as it is my right to not connect to you. > > Mind if I ask why you think you have any right to connect to my > network if I do not want you to do so? For _any_ reason, including > not showing me "legit" customers, political affiliation, or even the > color of your hat? amidst all this high flyin' political theory discussion of rights, there is an elephant in the room. as conditions to merger/purchase, there were legal restrictions placed on one or more significant operators regarding [de-]peering (i.e. your statement above is significantly incorrect). my altzheimer's device tells me that those restrictions end 2008.12.31. expect change. randy From patrick at ianai.net Thu Sep 11 17:58:44 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 11 Sep 2008 18:58:44 -0400 Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: <48C9A143.1080709@psg.com> References: <20080908112049.256D9BBE@resin13.mta.everyone.net> <200809110850.25652.lowen@pari.edu> <5D20455D-01B1-4406-AAEE-FFD9654DDF59@ianai.net> <48C9A143.1080709@psg.com> Message-ID: <991135A7-9F8D-4298-83E4-E337600AAA46@ianai.net> On Sep 11, 2008, at 6:52 PM, Randy Bush wrote: >>> In the internet world, mass depeering / de-transitting like we've >>> see in this instance is akin to capital punishment. By vigilantes. >>> The US Old West redux. >> Connecting to my network is a PRIVILEGE, not a right. You lose a >> criminal case, you lose rights (e.g. freedom to walk outside). >> Disconnecting you from my network is not denying any of your rights. >> >> There is no law or even custom stopping me from asking you to prove >> you are worthy to connect to my network. You don't want to prove it, >> that's your right, just as it is my right to not connect to you. >> >> Mind if I ask why you think you have any right to connect to my >> network if I do not want you to do so? For _any_ reason, including >> not showing me "legit" customers, political affiliation, or even the >> color of your hat? > > amidst all this high flyin' political theory discussion of rights, > there > is an elephant in the room. as conditions to merger/purchase, there > were legal restrictions placed on one or more significant operators > regarding [de-]peering (i.e. your statement above is significantly > incorrect). my altzheimer's device tells me that those restrictions > end > 2008.12.31. expect change. The fact there is a temporary exception to the rule for two providers in the US who agreed to the exception for reasons other than peering / transit does not mean the rule is invalid. As for (some of?) the exceptions expiring at the end of this calendar year, I'm not at all certain it will be a sea change. Contrary to popular belief, the US is not the center of the Internet any more. And even if it were, those providers - even the two combined - are not the center of the US Internet. Besides, wouldn't that just prove the rule anyway? :) The 'Net has become much more egalitarian. I would think that you of all people Randy would applaud the internationalization and flattening of the Internet. -- TTFN, patrick From repstein at chello.at Thu Sep 11 17:56:18 2008 From: repstein at chello.at (Randy Epstein) Date: Thu, 11 Sep 2008 18:56:18 -0400 Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: <48C9A143.1080709@psg.com> References: <20080908112049.256D9BBE@resin13.mta.everyone.net> <200809110850.25652.lowen@pari.edu><5D20455D-01B1-4406-AAEE-FFD9654DDF59@ianai.net> <48C9A143.1080709@psg.com> Message-ID: <18CAB802134440A2B2F9C86AFE65F867@D88CFA77634F40F> >amidst all this high flyin' political theory discussion of rights, there >is an elephant in the room. as conditions to merger/purchase, there >were legal restrictions placed on one or more significant operators >regarding [de-]peering (i.e. your statement above is significantly >incorrect). my altzheimer's device tells me that those restrictions end >2008.12.31. expect change. > >randy SBC end-date is 2009-Dec-31. Randy From randy at psg.com Thu Sep 11 18:10:05 2008 From: randy at psg.com (Randy Bush) Date: Fri, 12 Sep 2008 08:10:05 +0900 Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: <991135A7-9F8D-4298-83E4-E337600AAA46@ianai.net> References: <20080908112049.256D9BBE@resin13.mta.everyone.net> <200809110850.25652.lowen@pari.edu> <5D20455D-01B1-4406-AAEE-FFD9654DDF59@ianai.net> <48C9A143.1080709@psg.com> <991135A7-9F8D-4298-83E4-E337600AAA46@ianai.net> Message-ID: <48C9A54D.3030001@psg.com> >> amidst all this high flyin' political theory discussion of rights, there >> is an elephant in the room. as conditions to merger/purchase, there >> were legal restrictions placed on one or more significant operators >> regarding [de-]peering (i.e. your statement above is significantly >> incorrect). my altzheimer's device tells me that those restrictions end >> 2008.12.31. expect change. > The fact there is a temporary exception to the rule for two providers in > the US who agreed to the exception for reasons other than peering / > transit does not mean the rule is invalid. so sorry to have interrupted a deep discussion of political theory on rights and unwritten rules with operational reality :) randy From lowen at pari.edu Thu Sep 11 20:11:32 2008 From: lowen at pari.edu (Lamar Owen) Date: Thu, 11 Sep 2008 21:11:32 -0400 Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: <5D20455D-01B1-4406-AAEE-FFD9654DDF59@ianai.net> References: <20080908112049.256D9BBE@resin13.mta.everyone.net> Message-ID: <200809112111.33074.lowen@pari.edu> On Thursday 11 September 2008 18:37:59 Patrick W. Gilmore wrote: > On Sep 11, 2008, at 8:50 AM, Lamar Owen wrote: > > On Thursday 11 September 2008 06:23:29 list-nanog at pwns.ms wrote: > >> This is not a court. In court, if you are determined guilty a large > >> punishment may be exacted > > > > Depeering is not a large punishment? > > > > In the internet world, mass depeering / de-transitting like we've > > see in this > > instance is akin to capital punishment. By vigilantes. The US Old > > West > > redux. > > You are confused. No, I'm not, actually. As you say, it's every man (peer) for himself; is this not a digital analog to the dynamic of the Old West? If I have either a peering agreement or a transit arrangement with a written contract, then that contract supports my 'rights' under that contract persuant to my responsibilities being fulfilled. But here on NANOG it sure looked like the gunfight at the OK Corral earlier as the posse went after the bad guys. And, well, yes, the alleged 'bad guys' might have deserved the penalty. But it was sure an interesting dynamic to watch. Go back and read the whole thread; it is very enlightening. But you don't have to get all defensive about it. From patrick at ianai.net Thu Sep 11 20:59:48 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 11 Sep 2008 21:59:48 -0400 Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: <48C9A54D.3030001@psg.com> References: <20080908112049.256D9BBE@resin13.mta.everyone.net> <200809110850.25652.lowen@pari.edu> <5D20455D-01B1-4406-AAEE-FFD9654DDF59@ianai.net> <48C9A143.1080709@psg.com> <991135A7-9F8D-4298-83E4-E337600AAA46@ianai.net> <48C9A54D.3030001@psg.com> Message-ID: <73720B61-B4A7-406C-A0DD-4CDE35368E11@ianai.net> On Sep 11, 2008, at 7:10 PM, Randy Bush wrote: >>> amidst all this high flyin' political theory discussion of rights, >>> there >>> is an elephant in the room. as conditions to merger/purchase, there >>> were legal restrictions placed on one or more significant operators >>> regarding [de-]peering (i.e. your statement above is significantly >>> incorrect). my altzheimer's device tells me that those >>> restrictions end >>> 2008.12.31. expect change. >> The fact there is a temporary exception to the rule for two >> providers in >> the US who agreed to the exception for reasons other than peering / >> transit does not mean the rule is invalid. > > so sorry to have interrupted a deep discussion of political theory on > rights and unwritten rules with operational reality :) Cute. :-) But the "operational reality" is that you have no real expectation of connectivity to any other network. -- TTFN, patrick From jeff-kell at utc.edu Thu Sep 11 21:01:14 2008 From: jeff-kell at utc.edu (Jeff Kell) Date: Thu, 11 Sep 2008 22:01:14 -0400 Subject: Charter weirdness... Message-ID: <48C9CD6A.4040404@utc.edu> Anyone here with Charter? Please contact me off-list unless you're already aware of DNS weirdness... Jeff From patrick at ianai.net Thu Sep 11 21:23:35 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 11 Sep 2008 22:23:35 -0400 Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: <200809112111.33074.lowen@pari.edu> References: <20080908112049.256D9BBE@resin13.mta.everyone.net> <200809112111.33074.lowen@pari.edu> Message-ID: <60FE9DDD-472F-4C6E-A190-1CB5E51C78A6@ianai.net> On Sep 11, 2008, at 9:11 PM, Lamar Owen wrote: > On Thursday 11 September 2008 18:37:59 Patrick W. Gilmore wrote: >> On Sep 11, 2008, at 8:50 AM, Lamar Owen wrote: >>> On Thursday 11 September 2008 06:23:29 list-nanog at pwns.ms wrote: >>>> This is not a court. In court, if you are determined guilty a large >>>> punishment may be exacted >>> >>> Depeering is not a large punishment? >>> >>> In the internet world, mass depeering / de-transitting like we've >>> see in this >>> instance is akin to capital punishment. By vigilantes. The US Old >>> West >>> redux. >> >> You are confused. > > No, I'm not, actually. We disagree. > As you say, it's every man (peer) for himself; is this > not a digital analog to the dynamic of the Old West? > > If I have either a peering agreement or a transit arrangement with a > written > contract, then that contract supports my 'rights' under that contract > persuant to my responsibilities being fulfilled. If you had ever read a peering agreement, you would know they contain no guarantees of connectivity. Your rights are actually set forth as to what you may not do (e.g. point default), not what you may do (e.g. connect to me). Well, unless you include "disconnect from me" as a right. As for transit agreements, note that the network in question was kicked off both its transit providers in essentially nothing flat, so they obviously are not guaranteed either. (Not to mention at least two more the transit providers previous to this thread.) > But here on NANOG it sure looked like the gunfight at the OK Corral > earlier as > the posse went after the bad guys. And, well, yes, the alleged 'bad > guys' > might have deserved the penalty. But it was sure an interesting > dynamic to > watch. Go back and read the whole thread; it is very enlightening. Perhaps you should read up more on the "alleged" bad guys. I like to think of myself as a very open minded person, but child pr0n tends to upset essentially everyone. (And no, we are not talking 17 year olds, or even teenagers.) > But you don't have to get all defensive about it. Not defensive, educational. From the tone and content of your posts, I made the - perhaps erroneous - assumption you were unclear on how and why networks interconnected. But to try and verify my assumption, I asked you a question, which you ignored: Mind if I ask why you think you have any right to connect to my network if I do not want you to do so? Although you verified my assumption anyway (see point you tried to make about peering agreements above). That said, I like to understand the root of your confusion, so I am still interested in your answer. -- TTFN, patrick From randy at psg.com Thu Sep 11 21:37:15 2008 From: randy at psg.com (Randy Bush) Date: Fri, 12 Sep 2008 11:37:15 +0900 Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: <200809112111.33074.lowen@pari.edu> References: <20080908112049.256D9BBE@resin13.mta.everyone.net> <200809112111.33074.lowen@pari.edu> Message-ID: <48C9D5DB.1000203@psg.com> > But here on NANOG it sure looked like the gunfight at the OK Corral > earlier as the posse went after the bad guys. we do not lack in self-righteousness or vigilanteism. and we seem to be wannabe lawyers, economists, and sociologists, though only the $dieties can guess why. as the industry has become more and more commoditized, the 'grey people' occupy most of middle management and sadly often senior management. our arrogance does not earn us creds with these folk, with customers, or with our peers [0]. it is sadly telling that is our major archive of tools and techniques of the operators' trade (yes, i think it is a trade), and it is not even well-linked from other sites. compare this to other trades or engineering disciplines. randy -- [0] - http://www.merit.edu/mail.archives/nanog/2000-08/msg00087.html From lowen at pari.edu Fri Sep 12 00:42:08 2008 From: lowen at pari.edu (Lamar Owen) Date: Fri, 12 Sep 2008 01:42:08 -0400 Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: <60FE9DDD-472F-4C6E-A190-1CB5E51C78A6@ianai.net> References: <20080908112049.256D9BBE@resin13.mta.everyone.net> Message-ID: <200809120142.08768.lowen@pari.edu> [On-list comment. Off-list comments longer.] On Thursday 11 September 2008 22:23:35 Patrick W. Gilmore wrote: > > If I have either a peering agreement or a transit arrangement with a > > written > > contract, then that contract supports my 'rights' under that contract > > persuant to my responsibilities being fulfilled. > If you had ever read a peering agreement, I have; see this publicly available peering agreement [0], where in clause 9 we find the wording "Neither party shall assign its rights under this Agreement without the prior written consent of the other party." In clause 5 we find the wording "If ... there are significant breaches of the conditions of this agreement, both parties reserve the right unilaterally to immediately terminate the agreement ..." See what lies under the points of ellipsis by reading the whole (2.5 page) agreement; it is succinct, clear, and a great model. Drifting off-topic; my participation in this thread terminated, unilaterally. [0] - http://www.vix.at/vix-aconet-pa.html (PDF) From marcus.sachs at verizon.com Fri Sep 12 03:29:13 2008 From: marcus.sachs at verizon.com (marcus.sachs at verizon.com) Date: Fri, 12 Sep 2008 04:29:13 -0400 Subject: New Intercage upstream Message-ID: <6BCAB7B989C2EA4AAD36652C14D4FB4551CEAD@FHDP1CCMXCV02.us.one.verizon.com> Looks like they found a new willing partner. AS32335 PACIFICINTERNETEXCHANGE-NET - Pacific Internet Exchange LLC. http://cidr-report.org/cgi-bin/as-report?as=AS27595 http://www.pacificinternetexchange.net/ Marc From fergdawg at netzero.net Fri Sep 12 05:19:39 2008 From: fergdawg at netzero.net (Paul Ferguson) Date: Fri, 12 Sep 2008 10:19:39 GMT Subject: New Intercage upstream Message-ID: <20080912.031939.14488.1@webmail03.vgs.untd.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- wrote: >Looks like they found a new willing partner. > >AS32335 PACIFICINTERNETEXCHANGE-NET - Pacific Internet Exchange LLC. > >http://cidr-report.org/cgi-bin/as-report?as=AS27595 > >http://www.pacificinternetexchange.net/ > Visualize: http://www.robtex.com/as/as27595.html - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFIykIwq1pz9mNUZTMRAlUfAKD0nQa1X76hPPi8JjKFfMfr0BNh/ACgseiF bC/0IwSYBSlUYXepSgyhMnc= =Fa3Q -----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 ge at linuxbox.org Fri Sep 12 05:42:55 2008 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 12 Sep 2008 05:42:55 -0500 (CDT) Subject: community real-time BGP hijack notification service Message-ID: Hi, WatchMy.Net is a new community service to alert you when your prefix has been hijacked, in real-time. Following the discussion on NANOG a couple of weeks ago on what to do if your prefix is hijacked, people mentioned that detection-wise, free services are limited (to certain communities or by not being real-time). The current fully public and free services will alert you with a few hours delay. Over labor day weekend we built a free real-time service. We invite people to try it out during our beta stage. Register for alerts at: http://www.watchmy.net/ We hope you find it useful, Avi Freedman, Andrew Fried && Gadi Evron. From woody at pch.net Fri Sep 12 06:40:12 2008 From: woody at pch.net (Bill Woodcock) Date: Fri, 12 Sep 2008 04:40:12 -0700 (PDT) Subject: New Intercage upstream In-Reply-To: <6BCAB7B989C2EA4AAD36652C14D4FB4551CEAD@FHDP1CCMXCV02.us.one.verizon.com> References: <6BCAB7B989C2EA4AAD36652C14D4FB4551CEAD@FHDP1CCMXCV02.us.one.verizon.com> Message-ID: On Fri, 12 Sep 2008 marcus.sachs at verizon.com wrote: > Looks like they found a new willing partner. I like how their web page says "Network Uptime: 03:56:55 up 1562 days, 17:51 (100%) 1 user, load average: 0.03, 0.03, 0.02" Now, the difference between host and network aside, I find the idea of their having one user a little amusing. I've seen that truck around the parking lot of 200 Paul. Tim P., you going to go have a little chat with them for us? -Bill From cidr-report at potaroo.net Fri Sep 12 07:00:02 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 12 Sep 2008 22:00:02 +1000 (EST) Subject: BGP Update Report Message-ID: <200809121200.m8CC02a9034008@wattle.apnic.net> BGP Update Report Interval: 11-Aug-08 -to- 11-Sep-08 (32 days) Observation Point: BGP Peering with AS2.0 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9583 271701 3.4% 208.5 -- SIFY-AS-IN Sify Limited 2 - AS1803 133578 1.7% 100.8 -- ICMNET-5 - Sprint 3 - AS4538 92290 1.2% 18.4 -- ERX-CERNET-BKB China Education and Research Network Center 4 - AS8151 81876 1.0% 35.9 -- Uninet S.A. de C.V. 5 - AS5691 76580 1.0% 5890.8 -- MITRE-AS-5 - The MITRE Corporation 6 - AS9051 66326 0.8% 419.8 -- IDM Autonomous System 7 - AS6389 61608 0.8% 14.1 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 8 - AS17488 44840 0.6% 30.9 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 9 - AS10396 44488 0.6% 644.8 -- COQUI-NET - DATACOM CARIBE, INC. 10 - AS14593 41447 0.5% 41447.0 -- BRAND-INSTITUTE - Brand Instiute, Inc. 11 - AS6663 40207 0.5% 326.9 -- EUROWEBRO Euroweb Romania SA 12 - AS20115 37632 0.5% 22.1 -- CHARTER-NET-HKY-NC - Charter Communications 13 - AS8866 36541 0.5% 113.5 -- BTC-AS Bulgarian Telecommunication Company Plc. 14 - AS209 36253 0.5% 7.5 -- ASN-QWEST - Qwest 15 - AS6298 36103 0.5% 17.4 -- COX-PHX - Cox Communications Inc. 16 - AS5056 35265 0.4% 306.7 -- INS-NET-2 - Iowa Network Services 17 - AS18231 35043 0.4% 141.9 -- EXATT-AS-AP IOL NETCOM LTD 18 - AS9198 31683 0.4% 137.8 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 19 - AS4755 30182 0.4% 17.4 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 20 - AS7018 30023 0.4% 20.4 -- ATT-INTERNET4 - AT&T WorldNet Services TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS14593 41447 0.5% 41447.0 -- BRAND-INSTITUTE - Brand Instiute, Inc. 2 - AS4184 26397 0.3% 13198.5 -- STORTEK-WHQ - Storage Technology Corporation 3 - AS29910 8451 0.1% 8451.0 -- IACP - INTL. ASSN OF CHIEF OF POLICEI 4 - AS5691 76580 1.0% 5890.8 -- MITRE-AS-5 - The MITRE Corporation 5 - AS8266 5031 0.1% 5031.0 -- NEXUSTEL Nexus Telecommunications 6 - AS43299 4988 0.1% 4988.0 -- TELECONTACT-AS Telecontact Ltd. 7 - AS38180 4105 0.1% 4105.0 -- ETPI-IDS-JOLLIBEE-AS-AP 6/Fth floor JOLLIBEE PLAZA, Emerald Ave. Ortigas Center Pasig City. 8 - AS28194 18995 0.2% 3799.0 -- 9 - AS23082 18933 0.2% 3786.6 -- MPHI - Michigan Public Health Institute 10 - AS30969 25965 0.3% 2596.5 -- TAN-NET TransAfrica Networks 11 - AS23917 1958 0.0% 1958.0 -- BRIBIE-NET-AS-AP Bribie Island Net Multihomed, Brisbane 12 - AS24491 1769 0.0% 1769.0 -- WORLDWEB-THAILAND-AS-AP Internet Service Provider Thailand 13 - AS44194 1616 0.0% 1616.0 -- FREIFUNK-BERLIN-AS Freifunk Berlin 14 - AS32011 1555 0.0% 1555.0 -- JOHO-NYC - Joho Capital, LLC 15 - AS29225 1462 0.0% 1462.0 -- TAIF-TELCOM-AS JSC TAIF-TELCOM 16 - AS9747 11643 0.1% 1455.4 -- EZINTERNET-AS-AP EZInternet Pty Ltd 17 - AS25321 1248 0.0% 1248.0 -- G4S-NET GROUP 4 SECURITAS Prague 18 - AS26276 5797 0.1% 1159.4 -- TIMKEN-USA - The Timken Company 19 - AS39794 1113 0.0% 1113.0 -- EL-KOZIENICE-AS Elektrownia Kozienice S.A. 20 - AS3944 4188 0.1% 1047.0 -- PARTAN-LAB - Partan & Partan TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 192.12.120.0/24 76442 0.9% AS5691 -- MITRE-AS-5 - The MITRE Corporation 2 - 194.126.143.0/24 61962 0.7% AS9051 -- IDM Autonomous System 3 - 221.134.222.0/24 59613 0.7% AS9583 -- SIFY-AS-IN Sify Limited 4 - 210.214.151.0/24 41763 0.5% AS9583 -- SIFY-AS-IN Sify Limited 5 - 12.8.7.0/24 41447 0.5% AS14593 -- BRAND-INSTITUTE - Brand Instiute, Inc. 6 - 210.210.112.0/24 34493 0.4% AS9583 -- SIFY-AS-IN Sify Limited 7 - 221.135.80.0/24 34127 0.4% AS9583 -- SIFY-AS-IN Sify Limited 8 - 221.135.251.0/24 31357 0.4% AS9583 -- SIFY-AS-IN Sify Limited 9 - 83.228.71.0/24 28703 0.3% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 10 - 221.128.192.0/18 26630 0.3% AS18231 -- EXATT-AS-AP IOL NETCOM LTD 11 - 72.50.96.0/20 24278 0.3% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 12 - 89.38.98.0/23 23111 0.3% AS6663 -- EUROWEBRO Euroweb Romania SA 13 - 196.42.0.0/20 19075 0.2% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 14 - 86.105.182.0/24 13985 0.2% AS6663 -- EUROWEBRO Euroweb Romania SA 15 - 195.251.5.0/24 13319 0.2% AS5408 -- GR-NET Greek Research & Technology Network, http://www.grnet.gr 16 - 199.117.144.0/22 13201 0.2% AS4184 -- STORTEK-WHQ - Storage Technology Corporation 17 - 129.80.0.0/16 13196 0.2% AS4184 -- STORTEK-WHQ - Storage Technology Corporation 18 - 196.27.104.0/21 12621 0.1% AS30969 -- TAN-NET TransAfrica Networks 19 - 89.4.131.0/24 12567 0.1% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 20 - 196.27.108.0/22 12556 0.1% AS30969 -- TAN-NET TransAfrica Networks 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 Sep 12 07:00:00 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 12 Sep 2008 22:00:00 +1000 (EST) Subject: The Cidr Report Message-ID: <200809121200.m8CC005H033990@wattle.apnic.net> This report has been generated at Fri Sep 12 21:18:50 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 05-09-08 279838 172577 06-09-08 280450 167662 07-09-08 280494 171189 08-09-08 280576 171196 09-09-08 280020 170156 10-09-08 280859 170396 11-09-08 281136 169348 12-09-08 279371 168974 AS Summary 29348 Number of ASes in routing system 12435 Number of ASes announcing only one prefix 5028 Largest number of prefixes announced by an AS AS4538 : ERX-CERNET-BKB China Education and Research Network Center 88406528 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'). --- 12Sep08 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 281127 168963 112164 39.9% All ASes AS4538 5028 885 4143 82.4% ERX-CERNET-BKB China Education and Research Network Center AS6389 4301 351 3950 91.8% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS209 2932 647 2285 77.9% ASN-QWEST - Qwest AS4755 1726 225 1501 87.0% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS1785 1653 434 1219 73.7% AS-PAETEC-NET - PaeTec Communications, Inc. AS6298 1966 758 1208 61.4% COX-PHX - Cox Communications Inc. AS17488 1378 283 1095 79.5% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4323 1516 460 1056 69.7% TWTC - tw telecom holdings, inc. AS8151 1601 560 1041 65.0% Uninet S.A. de C.V. AS22773 975 65 910 93.3% CCINET-2 - Cox Communications Inc. AS18566 1048 275 773 73.8% COVAD - Covad Communications Co. AS19262 948 191 757 79.9% VZGNI-TRANSIT - Verizon Internet Services Inc. AS11492 1210 472 738 61.0% CABLEONE - CABLE ONE AS2386 1554 908 646 41.6% INS-AS - AT&T Data Communications Services AS18101 764 135 629 82.3% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS9498 677 70 607 89.7% BBIL-AP BHARTI Airtel Ltd. AS6478 1155 579 576 49.9% ATT-INTERNET3 - AT&T WorldNet Services AS3356 975 436 539 55.3% LEVEL3 Level 3 Communications AS4766 903 401 502 55.6% KIXS-AS-KR Korea Telecom AS4808 629 155 474 75.4% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS855 594 127 467 78.6% CANET-ASN-4 - Bell Aliant AS17676 524 63 461 88.0% GIGAINFRA BB TECHNOLOGY Corp. AS4134 841 387 454 54.0% CHINANET-BACKBONE No.31,Jin-rong Street AS7011 918 475 443 48.3% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS22047 564 127 437 77.5% VTR BANDA ANCHA S.A. AS9443 522 86 436 83.5% INTERNETPRIMUS-AS-AP Primus Telecommunications AS7029 527 93 434 82.4% WINDSTREAM - Windstream Communications Inc AS7018 1426 994 432 30.3% ATT-INTERNET4 - AT&T WorldNet Services AS24560 582 154 428 73.5% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS4668 683 274 409 59.9% LGNET-AS-KR LG CNS Total 40120 11070 29050 72.4% Top 30 total Possible Bogus Routes 24.75.116.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 24.75.160.0/19 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.245.128.0/17 AS11492 CABLEONE - CABLE ONE 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.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.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 64.188.0.0/16 AS3356 LEVEL3 Level 3 Communications 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.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 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 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 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 91.207.4.0/22 AS47142 STEEPHOST-AS SteepHost DC-UA-SteepHost.COM Datacentre Allocation 91.207.8.0/23 AS47142 STEEPHOST-AS SteepHost DC-UA-SteepHost.COM Datacentre Allocation 91.208.199.0/24 AS35185 KUVEYTTURK-ASN Kuveyt Turk EFK A.S. 91.208.202.0/24 AS42652 INTRAPARK Intrapark GmbH 94.103.20.0/22 AS16243 VIRTU-AS Virtu Secure Webservices B.V. 94.125.240.0/21 AS41822 TNGS-NORTH-AS JSC Tyumenneftegazsvyaz 95.165.192.0/19 AS12479 UNI2-AS Uni2 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 121.50.12.0/24 AS38236 121.50.13.0/24 AS38236 121.50.14.0/24 AS38236 121.50.15.0/24 AS38236 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.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.248.0/23 AS680 DFN-IP service G-WiN 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.25.240.0/21 AS3209 Arcor IP-Network 193.25.246.0/24 AS3211 Arcor Data-Network 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 195.222.124.0/22 AS12714 TI-AS NetByNet Holding 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 - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 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.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.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.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.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.144.160.0/20 AS7296 ALCHEMYNET - Alchemy Communications, 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.220/32 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.241.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 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/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.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.74.96.0/20 AS16776 MOVE-CORP - Move Sales, Inc. 209.74.112.0/20 AS16776 MOVE-CORP - Move Sales, Inc. 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.127.124.0/23 AS2828 XO-AS15 - XO Communications 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.210.86.0/24 AS577 BACOM - Bell Canada 216.229.51.0/24 AS15211 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 arnaud at pnzone.net Fri Sep 12 07:18:58 2008 From: arnaud at pnzone.net (Arnaud de Prelle) Date: Fri, 12 Sep 2008 14:18:58 +0200 Subject: community real-time BGP hijack notification service In-Reply-To: References: Message-ID: <48CA5E32.8060504@pnzone.net> Hello Gadi, Gadi Evron wrote: > Hi, WatchMy.Net is a new community service to alert you when your prefix > has been hijacked, in real-time. Very good initiative. You can count on me as one of your users. Note that apparently it doesn't seem to be working as expected yet. Indeed I already received two false alerts: 1. Subject: watchmy.net BGP Alert - seeing {91.198.99.0/24, 6450 3737 701 702 43751} Body: Hello, we are seeing 91.198.99.0/24 being advertised with aspath 6450 3737 701 702 43751. We are alerting you because of the rule you set that is watching for prefixes that match or are more specific than 91.198.99.0/24, and are originated with any origin AS other than one of 702,6661,8220 Thanks, watchmy.net's jack-o-meter 2. Subject: watchmy.net BGP Alert - seeing {93.191.216.0/21, 6450 4436 3257 6661 43751} Body: Hello, we are seeing 93.191.216.0/21 being advertised with aspath 6450 4436 3257 6661 43751. We are alerting you because of the rule you set that is watching for prefixes that match or are more specific than 93.191.216.0/21, and are originated with any origin AS other than one of 702,6661,8220 Thanks, watchmy.net's jack-o-meter Is this normal? Regards, APN-RIPE. From andrews at ltinet.net Fri Sep 12 07:33:10 2008 From: andrews at ltinet.net (Andrew Staples) Date: Fri, 12 Sep 2008 20:33:10 +0800 Subject: NTT/ChinaTelCom troubleshooting In-Reply-To: References: <006D6E61F6B537498FBEB95E80A26E1E019F0507CD@NLI-CCR-SVR.nlightphotonics.com> <000301c911c8$3f1ee310$bd5ca930$@net> Message-ID: <001b01c914d3$ba254730$2e6fd590$@net> Many thanks to all the replies and help. There are some star performers working for NTT, kudos to them for their professionalism and brainpower. Follow-up question: We've seen great improvement by testing throughput using ChinaNetworkCommunications, AS4837. Before we switch service, does anyone have experience with their network/service/administration? Thanks, Andrew -----Original Message----- From: Andrew Staples [mailto:andrews at ltinet.net] Sent: Monday, September 08, 2008 8:33 AM To: nanog at nanog.org Subject: NTT/ChinaTelCom troubleshooting Our connectivity from the US to ChinaTelCom has been in the toilet for 2 months. The Olympics are over, and I'm assured by my Shanghai contacts that The Great Firewall of China has been relaxed, yet the problem remains. Local loops on each end test fine to other localized ip space. Symptoms include large-email delivery delays/failures, large file transfer failures. Firewalls and VPNs have been reviewed, NOCS have been contacted. Fingerpointing is raging at its finest. US endpoint is AS7358 Transit is AS2914 CN endpoint is AS4134 If there is anyone from those three networks who can help us figure out why large packets are dropping on transmits from the US to CN, I would really appreciate an off-list reply. Heck, I'll take any replies from anyone that might have some inside information or similar experiences, or give me some ideas on the best way to do some external black-hole router/mtu munging detective work on these networks. Thanks, Andrew From nanog at daork.net Fri Sep 12 07:49:49 2008 From: nanog at daork.net (Nathan Ward) Date: Sat, 13 Sep 2008 00:49:49 +1200 Subject: community real-time BGP hijack notification service In-Reply-To: References: Message-ID: On 12/09/2008, at 10:42 PM, Gadi Evron wrote: > Hi, WatchMy.Net is a new community service to alert you when your > prefix > has been hijacked, in real-time. Hi Gadi, I just had a quick play with this, as I've been considering hacking together something similar. It is trivially easy for an attacker to falsify the origin AS. If 'they' are not doing it already, then I'm quite surprised. This isn't really a good thing to alarm on, in my opinion. Or, maybe it is, but there should be big bold text explaining that it's not reliable as it's trivially easy to falsify. To be honest, I can't think of anything better, all the attributes you can monitor can easily be falsified. My best idea is looking at the AS_PATH for changes, and alerting whenever that happens. You'd obviously get a different path whenever there is churn in the network though. I'm sure there's a way to do this, and I suspect having BGP feeds from many many places is the most reliable way for it to happen, I just haven't figured out why yet. This seems like a service that Renesys etc. could/should (or maybe do?) offer, they seem well placed with all their BGP feeds.. -- Nathan Ward From christian at broknrobot.com Fri Sep 12 08:14:35 2008 From: christian at broknrobot.com (Christian Koch) Date: Fri, 12 Sep 2008 09:14:35 -0400 Subject: community real-time BGP hijack notification service In-Reply-To: References: Message-ID: I've been using IAR and PHAS, but I've noticed IAR seems to work a bit better and much faster. Recently we changed our ASN, and seconds after we started announcing prefixes under thew new ASN I received the email alerts from IAR. I did not receive anything from PHAS. Although I have in the past, PHAS seems to be unreliable at times. As for alerting on AS_PATH changes, I think that more false alarms would be generated given certain 'techniques' used to 're-route' traffic to use the best available path. (Internap/FCP). Maybe a better idea would be if you were able to input your origin asn and define your upstreams and/or peers, to be alerted on as well. (ie: Do not alert me on any paths containing 123_000, 456_000, 789_000). Christian On Fri, Sep 12, 2008 at 8:49 AM, Nathan Ward wrote: > On 12/09/2008, at 10:42 PM, Gadi Evron wrote: > >> Hi, WatchMy.Net is a new community service to alert you when your prefix >> has been hijacked, in real-time. > > > Hi Gadi, > > I just had a quick play with this, as I've been considering hacking together > something similar. > > It is trivially easy for an attacker to falsify the origin AS. If 'they' are > not doing it already, then I'm quite surprised. > This isn't really a good thing to alarm on, in my opinion. Or, maybe it is, > but there should be big bold text explaining that it's not reliable as it's > trivially easy to falsify. > > To be honest, I can't think of anything better, all the attributes you can > monitor can easily be falsified. > > My best idea is looking at the AS_PATH for changes, and alerting whenever > that happens. You'd obviously get a different path whenever there is churn > in the network though. I'm sure there's a way to do this, and I suspect > having BGP feeds from many many places is the most reliable way for it to > happen, I just haven't figured out why yet. > > This seems like a service that Renesys etc. could/should (or maybe do?) > offer, they seem well placed with all their BGP feeds.. > > -- > Nathan Ward > > > > > > From ge at linuxbox.org Fri Sep 12 08:21:59 2008 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 12 Sep 2008 08:21:59 -0500 (CDT) Subject: community real-time BGP hijack notification service In-Reply-To: <48CA5E32.8060504@pnzone.net> References: <48CA5E32.8060504@pnzone.net> Message-ID: On Fri, 12 Sep 2008, Arnaud de Prelle wrote: > Hello Gadi, > > Gadi Evron wrote: >> Hi, WatchMy.Net is a new community service to alert you when your prefix >> has been hijacked, in real-time. > > Very good initiative. You can count on me as one of your users. > > Note that apparently it doesn't seem to be working as expected yet. > Indeed I already received two false alerts: > > Is this normal? Avi is flying right now, when he lands he will reply directly. We will probably fix all glitches in a day or two. We appreciate you using the service, and helping us get it right! Gadi. > > Regards, > APN-RIPE. > From ge at linuxbox.org Fri Sep 12 08:26:02 2008 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 12 Sep 2008 08:26:02 -0500 (CDT) Subject: community real-time BGP hijack notification service In-Reply-To: References: Message-ID: On Sat, 13 Sep 2008, Nathan Ward wrote: > On 12/09/2008, at 10:42 PM, Gadi Evron wrote: > >> Hi, WatchMy.Net is a new community service to alert you when your prefix >> has been hijacked, in real-time. > > > Hi Gadi, > > I just had a quick play with this, as I've been considering hacking together > something similar. Thank you for taking a look, and if you like to join in and help develop it, you are welcome to. > It is trivially easy for an attacker to falsify the origin AS. If 'they' are > not doing it already, then I'm quite surprised. > This isn't really a good thing to alarm on, in my opinion. Or, maybe it is, > but there should be big bold text explaining that it's not reliable as it's > trivially easy to falsify. > > To be honest, I can't think of anything better, all the attributes you can > monitor can easily be falsified. > > My best idea is looking at the AS_PATH for changes, and alerting whenever > that happens. You'd obviously get a different path whenever there is churn in > the network though. I'm sure there's a way to do this, and I suspect having > BGP feeds from many many places is the most reliable way for it to happen, I > just haven't figured out why yet. You are possibly right, and you are absolutely right that verbosity and documentation need to be better. We'll get there, and hopefully not too long from now. This is a weekend project, although we definitely intend to get through out TO-DO list. > This seems like a service that Renesys etc. could/should (or maybe do?) > offer, they seem well placed with all their BGP feeds.. Probably so, but they are a commercial effort. > > -- > Nathan Ward > > > > > From nanog at daork.net Fri Sep 12 08:27:31 2008 From: nanog at daork.net (Nathan Ward) Date: Sat, 13 Sep 2008 01:27:31 +1200 Subject: community real-time BGP hijack notification service In-Reply-To: References: Message-ID: <0D35644E-6263-4B19-A3EC-E79BA5CCB2D0@daork.net> On 13/09/2008, at 1:14 AM, Christian Koch wrote: > Maybe a better idea would be if you were able to input your origin asn > and define your upstreams and/or peers, to be alerted on as well. (ie: > Do not alert me on any paths containing 123_000, 456_000, 789_000). Again, that is trivially easy to falsify. My best quick hack solution so far is to fire off a traceroute and make sure that the traceroute gets ICMP TTL expire messages from IP addresses that are in prefixes originated from all the ASes in the ASPATH. Still forgeable, but a bit more difficult.. still far from perfect though. -- Nathan Ward From ge at linuxbox.org Fri Sep 12 08:27:29 2008 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 12 Sep 2008 08:27:29 -0500 (CDT) Subject: community real-time BGP hijack notification service In-Reply-To: References: Message-ID: On Fri, 12 Sep 2008, Christian Koch wrote: > I've been using IAR and PHAS, but I've noticed IAR seems to work a > bit better and much faster. Recently we changed our ASN, and seconds > after we started announcing prefixes under thew new ASN I received the > email alerts from IAR. I did not receive anything from PHAS. Although > I have in the past, PHAS seems to be unreliable at times. > > As for alerting on AS_PATH changes, I think that more false alarms > would be generated given certain 'techniques' used to 're-route' > traffic to use the best available path. (Internap/FCP). > > Maybe a better idea would be if you were able to input your origin asn > and define your upstreams and/or peers, to be alerted on as well. (ie: > Do not alert me on any paths containing 123_000, 456_000, 789_000). To that I don't need to wait for Avi to land and reply: Absolutely, but that requires another weekend of hacking. :) > Christian > > On Fri, Sep 12, 2008 at 8:49 AM, Nathan Ward wrote: >> On 12/09/2008, at 10:42 PM, Gadi Evron wrote: >> >>> Hi, WatchMy.Net is a new community service to alert you when your prefix >>> has been hijacked, in real-time. >> >> >> Hi Gadi, >> >> I just had a quick play with this, as I've been considering hacking together >> something similar. >> >> It is trivially easy for an attacker to falsify the origin AS. If 'they' are >> not doing it already, then I'm quite surprised. >> This isn't really a good thing to alarm on, in my opinion. Or, maybe it is, >> but there should be big bold text explaining that it's not reliable as it's >> trivially easy to falsify. >> >> To be honest, I can't think of anything better, all the attributes you can >> monitor can easily be falsified. >> >> My best idea is looking at the AS_PATH for changes, and alerting whenever >> that happens. You'd obviously get a different path whenever there is churn >> in the network though. I'm sure there's a way to do this, and I suspect >> having BGP feeds from many many places is the most reliable way for it to >> happen, I just haven't figured out why yet. >> >> This seems like a service that Renesys etc. could/should (or maybe do?) >> offer, they seem well placed with all their BGP feeds.. >> >> -- >> Nathan Ward >> >> >> >> >> >> > From christian at broknrobot.com Fri Sep 12 08:49:39 2008 From: christian at broknrobot.com (Christian Koch) Date: Fri, 12 Sep 2008 09:49:39 -0400 Subject: community real-time BGP hijack notification service In-Reply-To: <0D35644E-6263-4B19-A3EC-E79BA5CCB2D0@daork.net> References: <0D35644E-6263-4B19-A3EC-E79BA5CCB2D0@daork.net> Message-ID: It is, agreed. But what is more likely; a simple a prefix hijack or an all out attack, manipulating origin as, and as_path? While the 2nd is possible, the first is the most likely, and the basis for all these "hijack alert" services. Christian On Fri, Sep 12, 2008 at 9:27 AM, Nathan Ward wrote: > On 13/09/2008, at 1:14 AM, Christian Koch wrote: > >> Maybe a better idea would be if you were able to input your origin asn >> and define your upstreams and/or peers, to be alerted on as well. (ie: >> Do not alert me on any paths containing 123_000, 456_000, 789_000). > > > Again, that is trivially easy to falsify. > > My best quick hack solution so far is to fire off a traceroute and make sure > that the traceroute gets ICMP TTL expire messages from IP addresses that are > in prefixes originated from all the ASes in the ASPATH. > Still forgeable, but a bit more difficult.. still far from perfect though. > > -- > Nathan Ward > > > > > > From andy at nosignal.org Fri Sep 12 09:07:38 2008 From: andy at nosignal.org (Andy Davidson) Date: Fri, 12 Sep 2008 15:07:38 +0100 Subject: community real-time BGP hijack notification service In-Reply-To: References: Message-ID: <6C848BB6-7C98-4BF4-93B9-01CBA32A0FC6@nosignal.org> On 12 Sep 2008, at 13:49, Nathan Ward wrote: > On 12/09/2008, at 10:42 PM, Gadi Evron wrote: >> Hi, WatchMy.Net is a new community service to alert you when your >> prefix >> has been hijacked, in real-time. > I just had a quick play with this, as I've been considering hacking > together something similar. Everyone with any interest in this topic should look at the MyASN service from the RIPE NCC (which I use and think is brilliant). http://www.ris.ripe.net/myasn.html " The MyASN service notifies network operators when a prefix is announced with an incorrect AS path. An AS path is seen as incorrect when it does not match with a regular expression. As not everyone is familiar with regular expressions, MyASN provides several easy ways to define typical checks, like "the origin of this prefix must be AS x" or "the origin of this prefix must be AS x and transit may be provided through y or z". However, as any AS path regular expression can be set, the MyASN service is suitable for regular expressions gurus as well. " To address Nathan's point, I recommend the RIPE service because for such a service to be ubiquitously useful, it needs to have many eyes (a view of routing tables at lots of points on the internet) which is where the very well peered situation of RIS comes into effect. At the last RIPE meeting I think i saw RIS had over 600 peers, which it collects at internet exchange points all over the world. best wishes Andy From arnaud at pnzone.net Fri Sep 12 09:25:26 2008 From: arnaud at pnzone.net (Arnaud de Prelle) Date: Fri, 12 Sep 2008 16:25:26 +0200 Subject: community real-time BGP hijack notification service In-Reply-To: <6C848BB6-7C98-4BF4-93B9-01CBA32A0FC6@nosignal.org> References: <6C848BB6-7C98-4BF4-93B9-01CBA32A0FC6@nosignal.org> Message-ID: <48CA7BD6.1090507@pnzone.net> Andy Davidson wrote: > > On 12 Sep 2008, at 13:49, Nathan Ward wrote: > >> On 12/09/2008, at 10:42 PM, Gadi Evron wrote: >>> Hi, WatchMy.Net is a new community service to alert you when your prefix >>> has been hijacked, in real-time. >> I just had a quick play with this, as I've been considering hacking >> together something similar. > > Everyone with any interest in this topic should look at the MyASN > service from the RIPE NCC (which I use and think is brilliant). > > http://www.ris.ripe.net/myasn.html > I think that most of us (me included) are already using it but the problem is that they don't have BGP collectors everywhere in the world. This is in fact a generic issue for BGP monitoring. So the more we get the best it is and that's why I'll be using Gadi's BGP monitoring tool (and any other that might come) in parallel with the one provided by the RIPE. Note that MyASN will soon be replaced by IS Alarms which is simpler and as efficient as MyASN: http://tinyurl.com/46kfd7 http://ripe.net/is/alarms/ Regards, Arnaud. From freedman at freedman.net Fri Sep 12 09:50:43 2008 From: freedman at freedman.net (Avi Freedman) Date: Fri, 12 Sep 2008 10:50:43 -0400 (EDT) Subject: community real-time BGP hijack notification service (fwd) Message-ID: <1221231055.17322.TMDA@freedman.net> Hi, Arnaud. The design is to only watch the origin ASN, not the other ASNs in the path. Support for doing something with the transit portion wof the AS_PATH will be added, probably a very simple "alert if X is in there" or "alert if Y is not in there". As others have said it's imperfect so ideas are welcome but the goal here is to try to keep it useful but simple. Thanks, Avi > Date: Fri, 12 Sep 2008 14:18:58 +0200 > From: Arnaud de Prelle > To: Gadi Evron > Cc: nanog at merit.edu > Subject: Re: community real-time BGP hijack notification service > > Hello Gadi, > > Gadi Evron wrote: > > Hi, WatchMy.Net is a new community service to alert you when your prefix > > has been hijacked, in real-time. > > Very good initiative. You can count on me as one of your users. > > Note that apparently it doesn't seem to be working as expected yet. > Indeed I already received two false alerts: > > 1. > Subject: > watchmy.net BGP Alert - seeing {91.198.99.0/24, 6450 3737 701 702 43751} > > Body: > Hello, we are seeing 91.198.99.0/24 being advertised with aspath 6450 > 3737 701 702 43751. > > We are alerting you because of the rule you set that is watching for > prefixes that match or are more specific than 91.198.99.0/24, and are > originated with any origin AS other than one of 702,6661,8220 From freedman at freedman.net Fri Sep 12 09:57:19 2008 From: freedman at freedman.net (Avi Freedman) Date: Fri, 12 Sep 2008 10:57:19 -0400 (EDT) Subject: community real-time BGP hijack notification service Message-ID: <1221231450.17537.TMDA@freedman.net> > Nathan wrote: > It is trivially easy for an attacker to falsify the origin AS. If 'they' are > not doing it already, then I'm quite surprised. > This isn't really a good thing to alarm on, in my opinion. Or, maybe it is, but > there should be big bold text explaining that it's not reliable as it's > trivially easy to falsify. Yep, true. However, there's the case that someone's just typo'd you, which has happened to, near, around, and by me more frequently than an actual jackification. There was the time I fumble-fingered some net99 space and Karl Denninger started tracking me down to threaten lawsuits (before, I might add, asking me to log into the offending device and change the config). Anyway, the other case is where there shouldn't be a more specific, and you still win. Otherwise, yes, origin AS can be forged but the transit part is even messier, I think. > My best idea is looking at the AS_PATH for changes, and alerting whenever that > happens. You'd obviously get a different path whenever there is churn in the > network though. I'm sure there's a way to do this, and I suspect having BGP > feeds from many many places is the most reliable way for it to happen, I just > haven't figured out why yet. As you point out, the Internet is a really noisy and messy place. Just doing the "different than usual" is something I resisted here because there's so much hidden partial transit that doesn't normally expose. More BGP feeds might just amplify that behavior, though the idea is to get more feeds in. > This seems like a service that Renesys etc. could/should (or maybe do?) offer, > they seem well placed with all their BGP feeds.. Not sure who else offers it; it seemed reasonable to do and see if it's useful. Gadi told me there was no free real-time alerting out there but I didn't really look into it. Certainly if anyone wants to see the dynamics, who has advertised what now and in the deep dark past, etc Renesys would be the place to go as far as I know. > Nathan Ward Avi From freedman at freedman.net Fri Sep 12 10:00:15 2008 From: freedman at freedman.net (Avi Freedman) Date: Fri, 12 Sep 2008 11:00:15 -0400 (EDT) Subject: community real-time BGP hijack notification service Message-ID: <1221231627.17746.TMDA@freedman.net> > Nathan wrote: > My best quick hack solution so far is to fire off a traceroute and make sure > that the traceroute gets ICMP TTL expire messages from IP addresses that are in > prefixes originated from all the ASes in the ASPATH. > Still forgeable, but a bit more difficult.. still far from perfect though. An interesting idea although I think the false positive rate would be very high with all of the filtering (and mismatch between traceroute and BGP topologies) that exists out there. It'd be interesting for someone to try and see how well it works though. (Any researchers hanging out on NANOG want to try a weekend project...) > Nathan Ward Avi From bill at edisys.co.uk Fri Sep 12 10:12:32 2008 From: bill at edisys.co.uk (William Hamilton) Date: Fri, 12 Sep 2008 16:12:32 +0100 (BST) Subject: New Intercage upstream In-Reply-To: References: <6BCAB7B989C2EA4AAD36652C14D4FB4551CEAD@FHDP1CCMXCV02.us.one.verizon.com> Message-ID: <32778.83.104.210.137.1221232352.squirrel@shiva.edisys.co.uk> > On Fri, 12 Sep 2008 marcus.sachs at verizon.com wrote: > > Looks like they found a new willing partner. > > I like how their web page says "Network Uptime: 03:56:55 up 1562 days, > 17:51 (100%) 1 user, load average: 0.03, 0.03, 0.02" > > Now, the difference between host and network aside, I find the idea of > their having one user a little amusing. What's amusing about having one user on that particular host? B From woody at pch.net Fri Sep 12 10:13:37 2008 From: woody at pch.net (Bill Woodcock) Date: Fri, 12 Sep 2008 08:13:37 -0700 (PDT) Subject: New Intercage upstream In-Reply-To: <32778.83.104.210.137.1221232352.squirrel@shiva.edisys.co.uk> References: <6BCAB7B989C2EA4AAD36652C14D4FB4551CEAD@FHDP1CCMXCV02.us.one.verizon.com> <32778.83.104.210.137.1221232352.squirrel@shiva.edisys.co.uk> Message-ID: On Fri, 12 Sep 2008, William Hamilton wrote: > What's amusing about having one user on that particular host? That's the _front page of their corporate web site_. It doesn't say "host" it says that's their _network_. -Bill From bill at edisys.co.uk Fri Sep 12 10:18:10 2008 From: bill at edisys.co.uk (William Hamilton) Date: Fri, 12 Sep 2008 16:18:10 +0100 (BST) Subject: New Intercage upstream In-Reply-To: References: <6BCAB7B989C2EA4AAD36652C14D4FB4551CEAD@FHDP1CCMXCV02.us.one.verizon.com> <32778.83.104.210.137.1221232352.squirrel@shiva.edisys.co.uk> Message-ID: <31482.83.104.210.137.1221232690.squirrel@shiva.edisys.co.uk> > On Fri, 12 Sep 2008, William Hamilton wrote: > > What's amusing about having one user on that particular host? > > That's the _front page of their corporate web site_. It doesn't say > "host" it says that's their _network_. > You already made that distinction - "Now, the difference between host and network aside" - although perhaps I misinterpreted your point. In that case, my apologies. B From eromijn at ripe.net Fri Sep 12 10:26:28 2008 From: eromijn at ripe.net (Erik Romijn) Date: Fri, 12 Sep 2008 17:26:28 +0200 Subject: community real-time BGP hijack notification service In-Reply-To: <1221231450.17537.TMDA@freedman.net> References: <1221231450.17537.TMDA@freedman.net> Message-ID: <48CA8A24.8010402@ripe.net> Avi Freedman wrote: > Certainly if anyone wants to see the dynamics, who has advertised what now and > in the deep dark past, etc Renesys would be the place to go as far as I know. RIS provides data in a searchable MySQL database for three months. All we've ever collected is kept in a raw data format. This archive starts in 1999, and we maintain a library to read the data. This data is free to use for any purpose and we will not remove any of our raw data as it gets older. We are also carefully looking into whether we should reduce or increase the amount of data in our MySQL database - as that's easy to search for our users. However, any increase obviously comes with increased resource usage - so this is something that requires careful thinking and planning. Another option is to store aggregated info on older data, instead of keeping every update that ever occured. But, this is just an idea that crosses our minds from time to time - I'm not making promises on what we will implement :) Of course, any ideas on how much more history would help you, are very welcome. cheers, -- Erik Romijn RIPE NCC software engineer http://www.ripe.net/ Information Services dept. From freedman at freedman.net Fri Sep 12 10:33:36 2008 From: freedman at freedman.net (Avi Freedman) Date: Fri, 12 Sep 2008 11:33:36 -0400 (EDT) Subject: community real-time BGP hijack notification service Message-ID: <1221233628.20486.TMDA@freedman.net> Hi Erik - There's a great button about Usenet - "Reading Usenet is like drinking from a firehose; Posting to Usenet is like shouting from a mountaintop; Archiving Usenet is like saving used toilet tissue." BGP may be somewhat more important, useful, and the results consumable in the short-term, but for long-term archiving I think it devolves to being more interested to researchers and other ubernerds who can use the libraries and the very valuable data store and service that RIPE provides (which is appreciated)! I was thinking more for the medium term "what's normal" that goes back beyond whatever's in the routing table this second, probably for a few weeks to months max in most cases. And I think for actual diagnosis what's needed is a great tool to ask network and business questions of historic BGP data. That's the context in which I mention Renesys tools+data. So I'd say to help the networkers of the world, it's probably more about tools than history. Thanks, Avi > RIS provides data in a searchable MySQL database for three months. > > All we've ever collected is kept in a raw data format. This archive > starts in 1999, and we maintain a library to read the data. > This data is free to use for any purpose and we will not remove any of > our raw data as it gets older. > > We are also carefully looking into whether we should reduce or increase > the amount of data in our MySQL database - as that's easy to search for > our users. > > However, any increase obviously comes with increased resource usage - so > this is something that requires careful thinking and planning. > Another option is to store aggregated info on older data, instead of > keeping every update that ever occured. > > But, this is just an idea that crosses our minds from time to time - I'm > not making promises on what we will implement :) > > Of course, any ideas on how much more history would help you, are very > welcome. > > cheers, > -- > Erik Romijn RIPE NCC software engineer > From christian at broknrobot.com Fri Sep 12 10:41:41 2008 From: christian at broknrobot.com (Christian Koch) Date: Fri, 12 Sep 2008 11:41:41 -0400 Subject: New Intercage upstream In-Reply-To: References: <6BCAB7B989C2EA4AAD36652C14D4FB4551CEAD@FHDP1CCMXCV02.us.one.verizon.com> <32778.83.104.210.137.1221232352.squirrel@shiva.edisys.co.uk> Message-ID: looks to me as if they are just using output of 'top' and displaying it there as it were for network stats. output of top from one of my boxes.. top - 11:39:48 up 3 days, 20:56, 3 users, load average: 0.07, 0.21, 0.16 On Fri, Sep 12, 2008 at 11:13 AM, Bill Woodcock wrote: > On Fri, 12 Sep 2008, William Hamilton wrote: > > What's amusing about having one user on that particular host? > > That's the _front page of their corporate web site_. It doesn't say > "host" it says that's their _network_. > > -Bill > > > From patrick at ianai.net Fri Sep 12 12:43:42 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 12 Sep 2008 13:43:42 -0400 Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: <200809120142.08768.lowen@pari.edu> References: <20080908112049.256D9BBE@resin13.mta.everyone.net> <200809120142.08768.lowen@pari.edu> Message-ID: <872B38BF-232D-4798-A764-5B1486A77791@ianai.net> On Sep 12, 2008, at 1:42 AM, Lamar Owen wrote: > [On-list comment. Off-list comments longer.] > > On Thursday 11 September 2008 22:23:35 Patrick W. Gilmore wrote: >>> If I have either a peering agreement or a transit arrangement with a >>> written >>> contract, then that contract supports my 'rights' under that >>> contract >>> persuant to my responsibilities being fulfilled. > >> If you had ever read a peering agreement, > > I have; see this publicly available peering agreement [0], where in > clause 9 > we find the wording "Neither party shall assign its rights under this > Agreement without the prior written consent of the other party." In > clause 5 > we find the wording "If ... there are significant breaches of the > conditions > of this agreement, both parties reserve the right unilaterally to > immediately > terminate the agreement ..." See what lies under the points of > ellipsis by > reading the whole (2.5 page) agreement; it is succinct, clear, and a > great > model. > > Drifting off-topic; my participation in this thread terminated, > unilaterally. Actually, peering is on-topic. I'm sure there are many others out there who are just as unaware of how things work on the Internet as you are. That said, I'm not sure how many of them can read a peering agreement come to the conclusion that you then have a "right" to connect to my network. Going back a bit in case you forgot, we were discussing the fact you have NO RIGHT to connect to my network, it is a privilege, not a right. You responded with: "If I have either a peering agreement ... then that contract supports my 'rights' under that contract persuant to my responsibilities being fulfilled." Then you posted this contract as an example of those "rights". From the contract you claim to be "a great model": Each party?s entire liability and sole remedies, whether in contract or in tort, in respect of any default shall be as set out in this Clause or Clause 5. Each party?s remedies against the other in respect of any default shall be limited to damages and/or termination of this agreement. I guess you could argue you have a right - at least until I type "shut" on your BGP sessions. Then your rights end. I need no reasoning to do this. None. And your recourse once I have done this is.... Hrmm, it seems your only recourse is to type "shut" on your side of the session. Yeah, lots of rights there. Now, in practice, it is poor manners, and poor business judgement to shut someone off without notice. It hurts your customers and mine, and puts a very large strain on any other business dealings we have in progress or might have in the future. But manners and business deals are not rights. That should be plainly obvious to you (I hope). Oh, and I notice you ignored my question, again. I won't bother copy/ pasting it here just to have you continue to ignore it, I think the audience gets the point - you don't have an answer. -- TTFN, patrick From patrick at ianai.net Fri Sep 12 12:53:10 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 12 Sep 2008 13:53:10 -0400 Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: <872B38BF-232D-4798-A764-5B1486A77791@ianai.net> References: <20080908112049.256D9BBE@resin13.mta.everyone.net> <200809120142.08768.lowen@pari.edu> <872B38BF-232D-4798-A764-5B1486A77791@ianai.net> Message-ID: <2DB55491-5218-418C-BB43-9C3AF84F09F7@ianai.net> On Sep 12, 2008, at 1:43 PM, Patrick W. Gilmore wrote: > Oh, and I notice you ignored my question, again. I won't bother > copy/pasting it here just to have you continue to ignore it, I think > the audience gets the point - you don't have an answer. In fairness, he sent me an answer privately. Sorry, I didn't see that before I sent my on-list reply. -- TTFN, patrick From cscora at apnic.net Fri Sep 12 13:08:34 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 13 Sep 2008 04:08:34 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200809121808.m8CI8Y3v011242@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 13 Sep, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 268412 Prefixes after maximum aggregation: 129628 Deaggregation factor: 2.07 Unique aggregates announced to Internet: 130442 Total ASes present in the Internet Routing Table: 29220 Prefixes per ASN: 9.19 Origin-only ASes present in the Internet Routing Table: 25414 Origin ASes announcing only one prefix: 12361 Transit ASes present in the Internet Routing Table: 3806 Transit-only ASes present in the Internet Routing Table: 87 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 26 Max AS path prepend of ASN ( 3816) 15 Prefixes from unregistered ASNs in the Routing Table: 561 Unregistered ASNs in the Routing Table: 209 Number of 32-bit ASNs allocated by the RIRs: 60 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: 767 Number of addresses announced to Internet: 1916473632 Equivalent to 114 /8s, 59 /16s and 17 /24s Percentage of available address space announced: 51.7 Percentage of allocated address space announced: 62.8 Percentage of available address space allocated: 82.3 Percentage of address space in use by end-sites: 73.5 Total number of prefixes smaller than registry allocations: 131675 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 62162 Total APNIC prefixes after maximum aggregation: 22841 APNIC Deaggregation factor: 2.72 Prefixes being announced from the APNIC address blocks: 59072 Unique aggregates announced from the APNIC address blocks: 26366 APNIC Region origin ASes present in the Internet Routing Table: 3375 APNIC Prefixes per ASN: 17.50 APNIC Region origin ASes announcing only one prefix: 908 APNIC Region transit ASes present in the Internet Routing Table: 531 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 19 Number of APNIC addresses announced to Internet: 376051488 Equivalent to 22 /8s, 106 /16s and 23 /24s Percentage of available APNIC address space announced: 80.1 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: 121875 Total ARIN prefixes after maximum aggregation: 64530 ARIN Deaggregation factor: 1.89 Prefixes being announced from the ARIN address blocks: 91148 Unique aggregates announced from the ARIN address blocks: 34980 ARIN Region origin ASes present in the Internet Routing Table: 12439 ARIN Prefixes per ASN: 7.33 ARIN Region origin ASes announcing only one prefix: 4806 ARIN Region transit ASes present in the Internet Routing Table: 1193 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 16 Number of ARIN addresses announced to Internet: 361286880 Equivalent to 21 /8s, 136 /16s and 204 /24s Percentage of available ARIN address space announced: 74.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: 58112 Total RIPE prefixes after maximum aggregation: 35166 RIPE Deaggregation factor: 1.65 Prefixes being announced from the RIPE address blocks: 53245 Unique aggregates announced from the RIPE address blocks: 35726 RIPE Region origin ASes present in the Internet Routing Table: 11863 RIPE Prefixes per ASN: 4.49 RIPE Region origin ASes announcing only one prefix: 6234 RIPE Region transit ASes present in the Internet Routing Table: 1805 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 26 Number of RIPE addresses announced to Internet: 371846720 Equivalent to 22 /8s, 41 /16s and 238 /24s Percentage of available RIPE address space announced: 85.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: 21616 Total LACNIC prefixes after maximum aggregation: 5369 LACNIC Deaggregation factor: 4.03 Prefixes being announced from the LACNIC address blocks: 19815 Unique aggregates announced from the LACNIC address blocks: 10925 LACNIC Region origin ASes present in the Internet Routing Table: 997 LACNIC Prefixes per ASN: 19.87 LACNIC Region origin ASes announcing only one prefix: 330 LACNIC Region transit ASes present in the Internet Routing Table: 171 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 21 Number of LACNIC addresses announced to Internet: 55251968 Equivalent to 3 /8s, 75 /16s and 20 /24s Percentage of available LACNIC address space announced: 54.9 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: 4086 Total AfriNIC prefixes after maximum aggregation: 1260 AfriNIC Deaggregation factor: 3.24 Prefixes being announced from the AfriNIC address blocks: 4403 Unique aggregates announced from the AfriNIC address blocks: 2012 AfriNIC Region origin ASes present in the Internet Routing Table: 256 AfriNIC Prefixes per ASN: 17.20 AfriNIC Region origin ASes announcing only one prefix: 83 AfriNIC Region transit ASes present in the Internet Routing Table: 53 Average AfriNIC Region AS path length visible: 4.0 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 12717312 Equivalent to 0 /8s, 194 /16s and 13 /24s Percentage of available AfriNIC address space announced: 37.9 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 1718 538 181 Videsh Sanchar Nigam Ltd. Aut 17488 1378 93 98 Hathway IP Over Cable Interne 9583 1146 89 487 Sify Limited 4766 876 6408 360 Korea Telecom (KIX) 4134 841 13651 345 CHINANET-BACKBONE 23577 818 34 693 Korea Telecom (ATM-MPLS) 18101 766 152 51 Reliance Infocom Ltd Internet 4780 714 353 61 Digital United Inc. 9498 676 291 54 BHARTI BT INTERNET LTD. 4808 629 1156 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 4298 3416 339 bellsouth.net, inc. 209 2918 3873 620 Qwest 6298 1965 314 757 Cox Communicatons 20115 1677 1414 719 Charter Communications 1785 1653 710 156 AppliedTheory Corporation 2386 1555 691 895 AT&T Data Communications Serv 4323 1520 1073 375 Time Warner Telecom 7018 1405 5801 974 AT&T WorldNet Services 11492 1210 151 19 Cable One 6478 1155 240 185 AT&T Worldnet Services 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 420 1777 377 TDC Tele Danmark 3301 334 1460 305 TeliaNet Sweden 8452 328 188 11 TEDATA 3215 327 2756 106 France Telecom Transpac 3320 326 7063 274 Deutsche Telekom AG 30890 323 87 176 SC Kappa Invexim SRL 8866 317 77 21 Bulgarian Telecommunication C 5462 296 794 27 Telewest Broadband 8551 286 270 37 Bezeq International 680 275 2047 265 DFN-IP service G-WiN 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 1604 2607 222 UniNet S.A. de C.V. 11830 667 299 9 Instituto Costarricense de El 22047 564 270 14 VTR PUNTO NET S.A. 7303 486 239 67 Telecom Argentina Stet-France 16814 426 27 10 NSS, S.A. 10620 424 104 62 TVCABLE BOGOTA 6471 420 85 48 ENTEL CHILE S.A. 11172 409 118 72 Servicios Alestra S.A de C.V 28573 350 442 29 NET Servicos de Comunicao S.A 14117 345 23 9 Telefonica del Sur S.A. 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 512 67 32 LINKdotNET AS number 20858 403 34 3 EgyNet 3741 265 855 223 The Internet Solution 2018 231 214 138 Tertiary Education Network 6713 143 135 11 Itissalat Al-MAGHRIB 33783 137 10 13 EEPAD TISP TELECOM & INTERNET 5536 120 8 17 Internet Egypt Network 5713 118 555 68 Telkom SA Ltd 33776 116 6 3 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 4298 3416 339 bellsouth.net, inc. 209 2918 3873 620 Qwest 6298 1965 314 757 Cox Communicatons 4755 1718 538 181 Videsh Sanchar Nigam Ltd. Aut 20115 1677 1414 719 Charter Communications 1785 1653 710 156 AppliedTheory Corporation 8151 1604 2607 222 UniNet S.A. de C.V. 2386 1555 691 895 AT&T Data Communications Serv 4323 1520 1073 375 Time Warner Telecom 7018 1405 5801 974 AT&T WorldNet Services Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2918 2298 Qwest 4755 1718 1537 Videsh Sanchar Nigam Ltd. Aut 1785 1653 1497 AppliedTheory Corporation 8151 1604 1382 UniNet S.A. de C.V. 17488 1378 1280 Hathway IP Over Cable Interne 6298 1965 1208 Cox Communicatons 11492 1210 1191 Cable One 4323 1520 1145 Time Warner Telecom 18566 1048 1038 Covad Communications 6478 1155 970 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 7018 AT&T WorldNet Servic 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 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.75.160.0/19 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 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio 63.143.71.0/24 701 UUNET Technologies, Inc. 63.143.115.0/24 701 UUNET Technologies, Inc. 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:17 /11:45 /12:146 /13:294 /14:525 /15:1069 /16:10073 /17:4381 /18:7696 /19:16085 /20:19021 /21:18546 /22:23244 /23:24388 /24:140269 /25:784 /26:948 /27:747 /28:89 /29:9 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2851 4298 bellsouth.net, inc. 6298 1940 1965 Cox Communicatons 209 1684 2918 Qwest 2386 1232 1555 AT&T Data Communications Serv 11492 1191 1210 Cable One 17488 1185 1378 Hathway IP Over Cable Interne 1785 1122 1653 AppliedTheory Corporation 4755 1053 1718 Videsh Sanchar Nigam Ltd. Aut 6478 1048 1155 AT&T Worldnet Services 18566 1029 1048 Covad Communications Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:8 8:139 12:2140 13:2 15:21 16:3 17:5 18:13 20:35 24:1089 32:59 38:493 40:92 41:725 43:1 44:2 47:12 52:3 55:3 56:3 57:27 58:525 59:517 60:451 61:969 62:1213 63:2039 64:3193 65:2375 66:3454 67:1228 68:774 69:2274 70:844 71:164 72:1990 73:7 74:1150 75:164 76:265 77:793 78:824 79:265 80:947 81:833 82:580 83:366 84:575 85:1021 86:400 87:714 88:335 89:1360 90:21 91:1480 92:262 93:819 94:140 96:65 97:77 98:315 99:8 114:97 115:44 116:1015 117:362 118:243 119:488 120:83 121:591 122:845 123:438 124:853 125:1194 128:356 129:201 130:134 131:411 132:70 133:9 134:178 135:32 136:223 137:93 138:140 139:81 140:505 141:102 142:408 143:306 144:363 145:51 146:370 147:157 148:517 149:207 150:128 151:182 152:146 153:136 154:10 155:283 156:175 157:299 158:162 159:302 160:274 161:139 162:253 163:155 164:516 165:494 166:364 167:331 168:632 169:143 170:438 171:33 172:10 173:33 186:1 187:1 188:1 189:610 190:2210 192:5707 193:4145 194:3252 195:2573 196:996 198:3725 199:3294 200:5592 201:1528 202:7841 203:8071 204:3931 205:2120 206:2354 207:2738 208:3577 209:3421 210:2600 211:1093 212:1427 213:1625 214:179 215:50 216:4333 217:1213 218:346 219:437 220:1060 221:426 222:316 End of report From jra at baylink.com Fri Sep 12 13:24:50 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Fri, 12 Sep 2008 14:24:50 -0400 Subject: L(3) / 4/8 / multihoming In-Reply-To: <20080910205015.GL10282@cgi.jachomes.com> References: <20080910205015.GL10282@cgi.jachomes.com> Message-ID: <20080912182450.GO3221@cgi.jachomes.com> On Wed, Sep 10, 2008 at 04:50:15PM -0400, Jay R. Ashworth wrote: > I see in http://www.onesc.net/communities/as3356/ that L3 doesn't permit > customers to multihome the 4/8 space that they inherited from BBN, via > GTE, etc, ad nauseum... > > and I'm curious whether anyone knows why? It sounds like something there > might be an interesting story in... Lots of other people are curious, but no one knows the answers. One correspondent noted that Cogent did this with 38/8 when they bought PSI, but he didn't really know why... 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 lowen at pari.edu Fri Sep 12 13:24:33 2008 From: lowen at pari.edu (Lamar Owen) Date: Fri, 12 Sep 2008 14:24:33 -0400 Subject: New Intercage upstream In-Reply-To: <6BCAB7B989C2EA4AAD36652C14D4FB4551CEAD@FHDP1CCMXCV02.us.one.verizon.com> References: <6BCAB7B989C2EA4AAD36652C14D4FB4551CEAD@FHDP1CCMXCV02.us.one.verizon.com> Message-ID: <200809121424.34050.lowen@pari.edu> On Friday 12 September 2008 04:29:13 marcus.sachs at verizon.com wrote: > http://www.pacificinternetexchange.net/ For your reading enjoyments, their peering guidelines verbiage is at http://www.pacificinternetexchange.net/?page=peering and their transit SLA is at http://www.pacificinternetexchange.net/?page=sla The differences in the termination clauses of the two agreements make interesting reading. If a bit dull. In summary, for this specific network exchange's situations only: 1.) Peers may be terminated for a number of reasons (or for no reason at all, with 30 days notice). There is of course the normal 'no transit through our network' verbiage, and a temporary instant disconnect clause for serious problems (clauses 5.2 and 5.3). Patrick's favorite clause will likely be 5.5, where PIE reserves the right to refuse interconnection with or without any reason. I find it most interesting that they feel the need to enumerate an obvious right of a provider not normally worth mentioning. 2.) Customers have more rights than peers (obviously; consideration is changing hands). One relevant section is IV(C) of their SLA. They at least say the tough line against spam, and a depeering notice from one of their peers carries great weight (as it should, of course). But, in section IV(I) PIE makes a connection guarantee. That is their right to do, obviously, but gives the customer the right to the connection as long as the customer plays by the rules. No arbitrary disconnect ability there, for transit customers at least. The agreement even warrants that PIE has the authority to grant the rights under that agreement. Interesting wording. So if you want to be able to shut down a BGP session at a whim, you'd best make sure your agreement you executed allows for that; or exercise your right as a provider to refuse the customer, one or the other. It will be interesting to see how long this link stays active. And how long it takes for Intercage to find another upstream. Money talks. From joelja at bogus.com Fri Sep 12 13:33:43 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 12 Sep 2008 11:33:43 -0700 Subject: L(3) / 4/8 / multihoming In-Reply-To: <20080912182450.GO3221@cgi.jachomes.com> References: <20080910205015.GL10282@cgi.jachomes.com> <20080912182450.GO3221@cgi.jachomes.com> Message-ID: <48CAB607.5040402@bogus.com> Jay R. Ashworth wrote: > On Wed, Sep 10, 2008 at 04:50:15PM -0400, Jay R. Ashworth wrote: >> I see in http://www.onesc.net/communities/as3356/ that L3 doesn't permit >> customers to multihome the 4/8 space that they inherited from BBN, via >> GTE, etc, ad nauseum... >> >> and I'm curious whether anyone knows why? It sounds like something there >> might be an interesting story in... > > Lots of other people are curious, but no one knows the answers. One > correspondent noted that Cogent did this with 38/8 when they bought PSI, > but he didn't really know why... It's really hard to put the genie back in the bottle once you've let it out. considering the strategic significance of impending address exhaustion one imagines that they have their reasons. > Cheers, > - jra From oberman at es.net Fri Sep 12 13:43:50 2008 From: oberman at es.net (Kevin Oberman) Date: Fri, 12 Sep 2008 11:43:50 -0700 Subject: community real-time BGP hijack notification service In-Reply-To: Your message of "Fri, 12 Sep 2008 05:42:55 CDT." Message-ID: <20080912184350.F13D04500F@ptavv.es.net> Looks interesting, but it only takes a fairly short list of ASNs for a prefix. For our big CIDR blocks, we have WAY too many ASNs to enter them all, so it's pretty useless for me. I need to be able to enter at very least a dozen ASes and I suspect may folks have a LOT more then that. For now, I'll enter some shorter pieces from the block, but I'm most concerned with the pieces that are not currently assigned, so are available for hijack. I have added the larger, unassigned blocks. I'll start adding assigned bits and pieces as well as unassigned pieces, but being able to put all valid origin ASes in the list for the full blocks would be a lot nicer. -- 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 scg at gibbard.org Fri Sep 12 14:02:00 2008 From: scg at gibbard.org (Steve Gibbard) Date: Fri, 12 Sep 2008 12:02:00 -0700 (PDT) Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: <872B38BF-232D-4798-A764-5B1486A77791@ianai.net> References: <20080908112049.256D9BBE@resin13.mta.everyone.net> <200809120142.08768.lowen@pari.edu> <872B38BF-232D-4798-A764-5B1486A77791@ianai.net> Message-ID: <20080912114823.F44215@sprockets.gibbard.org> On Fri, 12 Sep 2008, Patrick W. Gilmore wrote: > Going back a bit in case you forgot, we were discussing the fact you have NO > RIGHT to connect to my network, it is a privilege, not a right. You > responded with: "If I have either a peering agreement ... then that contract > supports my 'rights' under that contract persuant to my responsibilities > being fulfilled." Then you posted this contract as an example of those > "rights". From the contract you claim to be "a great model": Calm down, Patrick. :) It's probably correct that any individual player in this industry not under other regulatory restrictions can refuse to do business with somebody they don't like, sometimes. For the industry as a whole to make a group decision to not do business with somebody who may be a competitor seems more legally risky. Engaging in that sort of thing without getting some good legal advice first would certainly make me nervous. Since this appears to be somebody who is contracting with lots of US providers, their identity is presumably known. This discussion has now been going on for long enough that it's presumably passed the emergency, "act now; think later," phase. Should what they're doing be a law enforcement issue, rather than a "they've got cooties" issue? -Steve From pauldotwall at gmail.com Fri Sep 12 14:03:21 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Fri, 12 Sep 2008 15:03:21 -0400 Subject: New Intercage upstream In-Reply-To: <6BCAB7B989C2EA4AAD36652C14D4FB4551CEAD@FHDP1CCMXCV02.us.one.verizon.com> References: <6BCAB7B989C2EA4AAD36652C14D4FB4551CEAD@FHDP1CCMXCV02.us.one.verizon.com> Message-ID: <620fd17c0809121203t25f8afa4l8e25a56c8b39606f@mail.gmail.com> This is easy. Hey Cogent (174), AboveNet (6461), and NTT/Verio (2914), Could you guys please be sure you're not routing the following rogue customer prefixes? 58.65.238.0/24 58.65.239.0/24 64.28.176.0/20 67.130.99.0/24 67.210.0.0/21 67.210.8.0/22 67.210.13.0/24 67.210.14.0/23 69.1.78.0/24 69.22.162.0/23 69.22.168.0/22 69.22.184.0/22 69.31.64.0/20 69.50.160.0/20 69.50.176.0/20 69.130.99.0/24 69.250.145.0/24 85.255.113.0/24 85.255.114.0/23 85.255.116.0/23 85.255.118.0/24 85.255.119.0/24 85.255.120.0/24 85.255.121.0/24 85.255.122.0/24 93.188.160.0/21 116.50.10.0/24 116.50.11.0/24 195.95.218.0/23 216.255.176.0/20 Thank you, and Drive Slow, Paul Wall On Fri, Sep 12, 2008 at 4:29 AM, wrote: > Looks like they found a new willing partner. > > AS32335 PACIFICINTERNETEXCHANGE-NET - Pacific Internet Exchange LLC. > > http://cidr-report.org/cgi-bin/as-report?as=AS27595 > > http://www.pacificinternetexchange.net/ > > > Marc > > From ge at linuxbox.org Fri Sep 12 14:03:59 2008 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 12 Sep 2008 14:03:59 -0500 (CDT) Subject: New Intercage upstream In-Reply-To: <200809121424.34050.lowen@pari.edu> References: <6BCAB7B989C2EA4AAD36652C14D4FB4551CEAD@FHDP1CCMXCV02.us.one.verizon.com> <200809121424.34050.lowen@pari.edu> Message-ID: On Fri, 12 Sep 2008, Lamar Owen wrote: > On Friday 12 September 2008 04:29:13 marcus.sachs at verizon.com wrote: >> http://www.pacificinternetexchange.net/ > > For your reading enjoyments, their peering guidelines verbiage is at > http://www.pacificinternetexchange.net/?page=peering and their transit SLA is > at http://www.pacificinternetexchange.net/?page=sla They don't seen to have ANY other clients than Intercage. Seems like the same operation to me. No? > The differences in the termination clauses of the two agreements make > interesting reading. If a bit dull. > > In summary, for this specific network exchange's situations only: > 1.) Peers may be terminated for a number of reasons (or for no reason at all, > with 30 days notice). There is of course the normal 'no transit through our > network' verbiage, and a temporary instant disconnect clause for serious > problems (clauses 5.2 and 5.3). Patrick's favorite clause will likely be > 5.5, where PIE reserves the right to refuse interconnection with or without > any reason. I find it most interesting that they feel the need to enumerate > an obvious right of a provider not normally worth mentioning. > > 2.) Customers have more rights than peers (obviously; consideration is > changing hands). One relevant section is IV(C) of their SLA. They at least > say the tough line against spam, and a depeering notice from one of their > peers carries great weight (as it should, of course). But, in section IV(I) > PIE makes a connection guarantee. That is their right to do, obviously, but > gives the customer the right to the connection as long as the customer plays > by the rules. No arbitrary disconnect ability there, for transit customers > at least. The agreement even warrants that PIE has the authority to grant the > rights under that agreement. Interesting wording. > > So if you want to be able to shut down a BGP session at a whim, you'd best > make sure your agreement you executed allows for that; or exercise your right > as a provider to refuse the customer, one or the other. > > It will be interesting to see how long this link stays active. And how long > it takes for Intercage to find another upstream. Money talks. > From ge at linuxbox.org Fri Sep 12 14:13:26 2008 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 12 Sep 2008 14:13:26 -0500 (CDT) Subject: community real-time BGP hijack notification service In-Reply-To: <20080912184350.F13D04500F@ptavv.es.net> References: <20080912184350.F13D04500F@ptavv.es.net> Message-ID: On Fri, 12 Sep 2008, Kevin Oberman wrote: > Looks interesting, but it only takes a fairly short list of ASNs for a > prefix. For our big CIDR blocks, we have WAY too many ASNs to enter them > all, so it's pretty useless for me. I need to be able to enter at very > least a dozen ASes and I suspect may folks have a LOT more then that. I am sure we can fix that, Thanks for the comment! > For now, I'll enter some shorter pieces from the block, but I'm most > concerned with the pieces that are not currently assigned, so are > available for hijack. I have added the larger, unassigned blocks. I'll > start adding assigned bits and pieces as well as unassigned pieces, but > being able to put all valid origin ASes in the list for the full blocks > would be a lot nicer. Please let us know if you encounter any issues. > -- > 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 Skywing at valhallalegends.com Fri Sep 12 14:16:02 2008 From: Skywing at valhallalegends.com (Skywing) Date: Fri, 12 Sep 2008 14:16:02 -0500 Subject: community real-time BGP hijack notification service In-Reply-To: References: <20080912184350.F13D04500F@ptavv.es.net> Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6BD9A9DC584@caralain.haven.nynaeve.net> It might be useful to have an option to generate an example alert mail for purposes of setting up necessary mail processing rules and that sort. Just a thought. - S -----Original Message----- From: Gadi Evron [mailto:ge at linuxbox.org] Sent: Friday, September 12, 2008 3:13 PM To: Kevin Oberman Cc: nanog at merit.edu Subject: Re: community real-time BGP hijack notification service On Fri, 12 Sep 2008, Kevin Oberman wrote: > Looks interesting, but it only takes a fairly short list of ASNs for a > prefix. For our big CIDR blocks, we have WAY too many ASNs to enter them > all, so it's pretty useless for me. I need to be able to enter at very > least a dozen ASes and I suspect may folks have a LOT more then that. I am sure we can fix that, Thanks for the comment! > For now, I'll enter some shorter pieces from the block, but I'm most > concerned with the pieces that are not currently assigned, so are > available for hijack. I have added the larger, unassigned blocks. I'll > start adding assigned bits and pieces as well as unassigned pieces, but > being able to put all valid origin ASes in the list for the full blocks > would be a lot nicer. Please let us know if you encounter any issues. > -- > 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 ge at linuxbox.org Fri Sep 12 14:15:45 2008 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 12 Sep 2008 14:15:45 -0500 (CDT) Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: <20080912114823.F44215@sprockets.gibbard.org> References: <20080908112049.256D9BBE@resin13.mta.everyone.net> <200809120142.08768.lowen@pari.edu> <872B38BF-232D-4798-A764-5B1486A77791@ianai.net> <20080912114823.F44215@sprockets.gibbard.org> Message-ID: On Fri, 12 Sep 2008, Steve Gibbard wrote: > On Fri, 12 Sep 2008, Patrick W. Gilmore wrote: > Since this appears to be somebody who is contracting with lots of US > providers, their identity is presumably known. This discussion has now been > going on for long enough that it's presumably passed the emergency, "act now; > think later," phase. Should what they're doing be a law enforcement issue, > rather than a "they've got cooties" issue? It wasn't an emergency except a PR emergency for the transit providers. As to a law enforcement issue, it probably is for 4 years now... which comes to show why we are the ones protecting the network. They will probably become more useful in the future. Gadi. > > -Steve > From pekkas at netcore.fi Fri Sep 12 14:22:55 2008 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 12 Sep 2008 22:22:55 +0300 (EEST) Subject: New Intercage upstream In-Reply-To: <620fd17c0809121203t25f8afa4l8e25a56c8b39606f@mail.gmail.com> References: <6BCAB7B989C2EA4AAD36652C14D4FB4551CEAD@FHDP1CCMXCV02.us.one.verizon.com> <620fd17c0809121203t25f8afa4l8e25a56c8b39606f@mail.gmail.com> Message-ID: On Fri, 12 Sep 2008, Paul Wall wrote: > This is easy. > > Hey Cogent (174), AboveNet (6461), and NTT/Verio (2914), > > Could you guys please be sure you're not routing the following rogue > customer prefixes? I think your argument might be more convincing with those NOCs/abuse-desks if you provided or referred to evidence which shows those prefixes don't belong to them. > 58.65.238.0/24 > 58.65.239.0/24 > 64.28.176.0/20 > 67.130.99.0/24 > 67.210.0.0/21 > 67.210.8.0/22 > 67.210.13.0/24 > 67.210.14.0/23 > 69.1.78.0/24 > 69.22.162.0/23 > 69.22.168.0/22 > 69.22.184.0/22 > 69.31.64.0/20 > 69.50.160.0/20 > 69.50.176.0/20 > 69.130.99.0/24 > 69.250.145.0/24 > 85.255.113.0/24 > 85.255.114.0/23 > 85.255.116.0/23 > 85.255.118.0/24 > 85.255.119.0/24 > 85.255.120.0/24 > 85.255.121.0/24 > 85.255.122.0/24 > 93.188.160.0/21 > 116.50.10.0/24 > 116.50.11.0/24 > 195.95.218.0/23 > 216.255.176.0/20 > > Thank you, and Drive Slow, > Paul Wall > > On Fri, Sep 12, 2008 at 4:29 AM, wrote: >> Looks like they found a new willing partner. >> >> AS32335 PACIFICINTERNETEXCHANGE-NET - Pacific Internet Exchange LLC. >> >> http://cidr-report.org/cgi-bin/as-report?as=AS27595 >> >> http://www.pacificinternetexchange.net/ >> >> >> Marc >> >> > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From andrew.fried at gmail.com Fri Sep 12 14:25:14 2008 From: andrew.fried at gmail.com (Andrew Fried) Date: Fri, 12 Sep 2008 15:25:14 -0400 Subject: community real-time BGP hijack notification service In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D6BD9A9DC584@caralain.haven.nynaeve.net> References: <20080912184350.F13D04500F@ptavv.es.net> <982D8D05B6407A49AD506E6C3AC8E7D6BD9A9DC584@caralain.haven.nynaeve.net> Message-ID: <48CAC21A.1080807@gmail.com> Mail being what it is today, testing message delivery is an excellent idea. I'll implement that feature this weekend. Andy Skywing wrote: > It might be useful to have an option to generate an example alert mail for purposes of setting up necessary mail processing rules and that sort. Just a thought. > > - S > > -----Original Message----- > From: Gadi Evron [mailto:ge at linuxbox.org] > Sent: Friday, September 12, 2008 3:13 PM > To: Kevin Oberman > Cc: nanog at merit.edu > Subject: Re: community real-time BGP hijack notification service > > On Fri, 12 Sep 2008, Kevin Oberman wrote: > >> Looks interesting, but it only takes a fairly short list of ASNs for a >> prefix. For our big CIDR blocks, we have WAY too many ASNs to enter them >> all, so it's pretty useless for me. I need to be able to enter at very >> least a dozen ASes and I suspect may folks have a LOT more then that. >> > > I am sure we can fix that, Thanks for the comment! > > >> For now, I'll enter some shorter pieces from the block, but I'm most >> concerned with the pieces that are not currently assigned, so are >> available for hijack. I have added the larger, unassigned blocks. I'll >> start adding assigned bits and pieces as well as unassigned pieces, but >> being able to put all valid origin ASes in the list for the full blocks >> would be a lot nicer. >> > > Please let us know if you encounter any issues. > > > >> -- >> 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 ge at linuxbox.org Fri Sep 12 14:25:34 2008 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 12 Sep 2008 14:25:34 -0500 (CDT) Subject: community real-time BGP hijack notification service In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D6BD9A9DC584@caralain.haven.nynaeve.net> References: <20080912184350.F13D04500F@ptavv.es.net> <982D8D05B6407A49AD506E6C3AC8E7D6BD9A9DC584@caralain.haven.nynaeve.net> Message-ID: On Fri, 12 Sep 2008, Skywing wrote: > It might be useful to have an option to generate an example alert mail for purposes of setting up necessary mail processing rules and that sort. Just a thought. Good point. Any suggestions from folks here on how they would like it to be built? > > - S > > -----Original Message----- > From: Gadi Evron [mailto:ge at linuxbox.org] > Sent: Friday, September 12, 2008 3:13 PM > To: Kevin Oberman > Cc: nanog at merit.edu > Subject: Re: community real-time BGP hijack notification service > > On Fri, 12 Sep 2008, Kevin Oberman wrote: >> Looks interesting, but it only takes a fairly short list of ASNs for a >> prefix. For our big CIDR blocks, we have WAY too many ASNs to enter them >> all, so it's pretty useless for me. I need to be able to enter at very >> least a dozen ASes and I suspect may folks have a LOT more then that. > > I am sure we can fix that, Thanks for the comment! > >> For now, I'll enter some shorter pieces from the block, but I'm most >> concerned with the pieces that are not currently assigned, so are >> available for hijack. I have added the larger, unassigned blocks. I'll >> start adding assigned bits and pieces as well as unassigned pieces, but >> being able to put all valid origin ASes in the list for the full blocks >> would be a lot nicer. > > Please let us know if you encounter any issues. > > >> -- >> 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 ge at linuxbox.org Fri Sep 12 14:50:06 2008 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 12 Sep 2008 14:50:06 -0500 (CDT) Subject: community real-time BGP hijack notification service In-Reply-To: <48CAC21A.1080807@gmail.com> References: <20080912184350.F13D04500F@ptavv.es.net> <982D8D05B6407A49AD506E6C3AC8E7D6BD9A9DC584@caralain.haven.nynaeve.net> <48CAC21A.1080807@gmail.com> Message-ID: On Fri, 12 Sep 2008, Andrew Fried wrote: > Mail being what it is today, testing message delivery is an excellent > idea. I'll implement that feature this weekend. I think he meant he wants to be able to get an example alert to his inbox on registration/on request so he can special filters which can wake him up. Gadi. > Andy > > Skywing wrote: >> It might be useful to have an option to generate an example alert mail for purposes of setting up necessary mail processing rules and that sort. Just a thought. >> >> - S >> >> -----Original Message----- >> From: Gadi Evron [mailto:ge at linuxbox.org] >> Sent: Friday, September 12, 2008 3:13 PM >> To: Kevin Oberman >> Cc: nanog at merit.edu >> Subject: Re: community real-time BGP hijack notification service >> >> On Fri, 12 Sep 2008, Kevin Oberman wrote: >> >>> Looks interesting, but it only takes a fairly short list of ASNs for a >>> prefix. For our big CIDR blocks, we have WAY too many ASNs to enter them >>> all, so it's pretty useless for me. I need to be able to enter at very >>> least a dozen ASes and I suspect may folks have a LOT more then that. >>> >> >> I am sure we can fix that, Thanks for the comment! >> >> >>> For now, I'll enter some shorter pieces from the block, but I'm most >>> concerned with the pieces that are not currently assigned, so are >>> available for hijack. I have added the larger, unassigned blocks. I'll >>> start adding assigned bits and pieces as well as unassigned pieces, but >>> being able to put all valid origin ASes in the list for the full blocks >>> would be a lot nicer. >>> >> >> Please let us know if you encounter any issues. >> >> >> >>> -- >>> 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 Valdis.Kletnieks at vt.edu Fri Sep 12 14:55:01 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 12 Sep 2008 15:55:01 -0400 Subject: New Intercage upstream In-Reply-To: Your message of "Fri, 12 Sep 2008 14:24:33 EDT." <200809121424.34050.lowen@pari.edu> References: <6BCAB7B989C2EA4AAD36652C14D4FB4551CEAD@FHDP1CCMXCV02.us.one.verizon.com> <200809121424.34050.lowen@pari.edu> Message-ID: <27426.1221249301@turing-police.cc.vt.edu> On Fri, 12 Sep 2008 14:24:33 EDT, Lamar Owen said: > peers carries great weight (as it should, of course). But, in section IV(I) > PIE makes a connection guarantee. That is their right to do, obviously, but Playing devil's advocate here - it guarantees a connection, but does it also guarantee that PIE won't null-route any of the customer's packets trying to leave PIE's network at an upstream peer/transit point? :) However, if Gadi's claim that they don't seem to have any clients other than Intercage is right, I'm sure the correct term for the connection guarantee is "bulletproof"... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From Bagga_Ajeet at emc.com Fri Sep 12 14:51:40 2008 From: Bagga_Ajeet at emc.com (Bagga_Ajeet at emc.com) Date: Fri, 12 Sep 2008 15:51:40 -0400 Subject: L(3) / 4/8 / multihoming In-Reply-To: <48CAB607.5040402@bogus.com> References: <20080910205015.GL10282@cgi.jachomes.com><20080912182450.GO3221@cgi.jachomes.com> <48CAB607.5040402@bogus.com> Message-ID: <76A60C1473BD3A468D304CC3F05A0CAD26048C@CORPUSMX80B.corp.emc.com> -----Original Message----- From: Joel Jaeggli [mailto:joelja at bogus.com] Sent: Friday, September 12, 2008 2:34 PM To: Jay R. Ashworth Cc: nanog at nanog.org Subject: Re: L(3) / 4/8 / multihoming Jay R. Ashworth wrote: >> On Wed, Sep 10, 2008 at 04:50:15PM -0400, Jay R. Ashworth wrote: >>> I see in http://www.onesc.net/communities/as3356/ that L3 doesn't permit >>> customers to multihome the 4/8 space that they inherited from BBN, via >>> GTE, etc, ad nauseum... Or, they inherited the directive - keep 4/8 pristine, aggregated, and absolute (BBN land - customers, infra), from BBN, too !?! >>> and I'm curious whether anyone knows why? It sounds like something there >>> might be an interesting story in... Besides the obvious; where their other upstream became transit for (a good portion of) 4/8, be it their or their other upstream's fault in screwing up the adverts!?! I imagine those numbered out of 4/8 that wished to multihome to another provider, requested IP renumbering from BBN from one of BBN's non-4/8 (promiscuous) blocks. But, I speculate. ~ Ajeet Bagga Sr. Network Engineer EMC From freedman at freedman.net Fri Sep 12 15:03:03 2008 From: freedman at freedman.net (Avi Freedman) Date: Fri, 12 Sep 2008 16:03:03 -0400 (EDT) Subject: community real-time BGP hijack notification service Message-ID: <1221249794.6713.TMDA@freedman.net> Hmm, I'm trying to figure out the application here. You have single prefixes originated or originate-able by more than 5 or 6 ASs? I see - is it that you have, say a /16 with 13 potential ASs that might be seen as originating more specifics inside that /16? Hadn't considered that; we were envisioning that those specifics would be set up as separate alerts. It's easy enough to extend the # of ASNs that can be listed, however. That'll be done this weekend. Thanks, Avi > Looks interesting, but it only takes a fairly short list of ASNs for a > prefix. For our big CIDR blocks, we have WAY too many ASNs to enter them > all, so it's pretty useless for me. I need to be able to enter at very > least a dozen ASes and I suspect may folks have a LOT more then that. > > For now, I'll enter some shorter pieces from the block, but I'm most > concerned with the pieces that are not currently assigned, so are > available for hijack. I have added the larger, unassigned blocks. I'll > start adding assigned bits and pieces as well as unassigned pieces, but > being able to put all valid origin ASes in the list for the full blocks > would be a lot nicer. > R. Kevin Oberman, Network Engineer From morrowc.lists at gmail.com Fri Sep 12 16:05:35 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 12 Sep 2008 17:05:35 -0400 Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: <20080912114823.F44215@sprockets.gibbard.org> References: <20080908112049.256D9BBE@resin13.mta.everyone.net> <200809120142.08768.lowen@pari.edu> <872B38BF-232D-4798-A764-5B1486A77791@ianai.net> <20080912114823.F44215@sprockets.gibbard.org> Message-ID: <75cb24520809121405h6568e9fci83c406701fbf20fe@mail.gmail.com> On 9/12/08, Steve Gibbard wrote: > It's probably correct that any individual player in this industry not under > other regulatory restrictions can refuse to do business with somebody they > don't like, sometimes. For the industry as a whole to make a group decision > to not do business with somebody who may be a competitor seems more legally > risky. Engaging in that sort of thing without getting some good legal > advice first would certainly make me nervous. the perception of collusion is interesting, I don't necessarily think it's happening here, but ianal (as patrick would say). What is happening here is that instead of a bunch of random 'hey something wierd is going on with that host over yonder' or 'wow that network has a lot of bad stuff on it today' someone succinctly put down in an open and public place the list of things that is going on and references to how bad it may actually be. So, instead of (for one example) GBLX-abuse getting onsey/twosy 'crazy guy' tickets/emails they have a chance to now correlate their internal info against abuse@ and other things and take some action. I don't know that that's the case with GBLX in this case, but I know at previous places of employment having lots of odd ranty emails never really helped. Having succint collections of info about a problem would make it simpler to address with management/bean-counters/lawyers and propose reasonable action(s) against the offendors. > > Since this appears to be somebody who is contracting with lots of US well, at least 2, only one 'large'... other smaller folks may have been: 1) too busy fighting their own fires to worry about someone paying ontime and (possibly) addressing abuse@ issues in a 'timely' fashion. (from the abuse@ queue it's not necessarily easy to tell that badip1 shifted to newip2 when you sent the complaint to the downstream, especially if you are already overwelmed with other fires) 2) too interested in the bills getting paid 3) unaware for a variety of reasons who their new customer really is/was > now; think later," phase. Should what they're doing be a law enforcement > issue, rather than a "they've got cooties" issue? with this particular network I've wondered this same thing for 4+ years. They were most obviously doing very bad things for a long period of time, at no time was there an reasonable LEA action taken that was evident form the outside. It's possible that with the forest of issues LEA is dealing with on the Intertubes they just aren't putting 1+1+2 together often enough and realizing there is a fairly clear pattern of criminal activity eminating from the same general place. For instance, I've corrected many folks on many occasions who've said: "Oh that badness is coming from the Ukraine... see the whois' info here:" organisation: ORG-UL25-RIPE org-name: UkrTeleGroup Ltd. org-type: LIR address: UkrTeleGroup Ltd. Mechnikova 58/5 65029 Odessa Ukraine Really? why does it traceroute to SFO then and die there on a host?? Why is it routed to a leaf AS in the US with a presence only in a single facility (200 Paul)?? I know of only a few folks who've put all of the pieces together in a reasonable package, and I don't think they can hand it all over (especially since it's not much good 2-3 weeks after the package is gathered due to the shifting sands of tubage) to LEA without it falling into the 'agent of LEA' part of evidence gathering :( Plus, LEA has to put priority on this sort of thing, and with so much going on I get the feeling focus is hard to accomplish... (I'd love to be proven wrong of course..) -Chris From morrowc.lists at gmail.com Fri Sep 12 16:15:47 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 12 Sep 2008 17:15:47 -0400 Subject: New Intercage upstream In-Reply-To: <200809121424.34050.lowen@pari.edu> References: <6BCAB7B989C2EA4AAD36652C14D4FB4551CEAD@FHDP1CCMXCV02.us.one.verizon.com> <200809121424.34050.lowen@pari.edu> Message-ID: <75cb24520809121415wc3ee040r434d3fbd46e0fe4f@mail.gmail.com> On 9/12/08, Lamar Owen wrote: > So if you want to be able to shut down a BGP session at a whim, you'd best > make sure your agreement you executed allows for that; or exercise your right > as a provider to refuse the customer, one or the other. So... one other option which I've seen exercised is to keep the bgp sessoin up and just not permit any routes in either direction. The 'customer connection' is still up, the link is pingable, all SLA's are satisfied, the network doesn't have to guarantee 'routability' only 'connection'. Most every US network (at least) has the ability to shut down interfaces/devices/sessions 'for the protection of their network', in the worst case they may have to refund charges for the monthly fees... though I'd note that in the place I saw the 'no routes' used no chargebacks occured, despite the angry sales-driods and customer(s). In any case, there's no 'right' just some potentially flimsy legal verbiage and 'we really dont want to make a habit of stomping on too many customers'. > It will be interesting to see how long this link stays active. And how long > it takes for Intercage to find another upstream. Money talks. agreed. From heather.schiller at verizonbusiness.com Fri Sep 12 17:23:49 2008 From: heather.schiller at verizonbusiness.com (Heather Schiller) Date: Fri, 12 Sep 2008 18:23:49 -0400 Subject: community real-time BGP hijack notification service In-Reply-To: References: <20080912184350.F13D04500F@ptavv.es.net> <982D8D05B6407A49AD506E6C3AC8E7D6BD9A9DC584@caralain.haven.nynaeve.net> Message-ID: <48CAEBF5.3080408@verizonbusiness.com> Gadi Evron wrote: > On Fri, 12 Sep 2008, Skywing wrote: >> It might be useful to have an option to generate an example alert mail >> for purposes of setting up necessary mail processing rules and that >> sort. Just a thought. > > Good point. Any suggestions from folks here on how they would like it to > be built? > Could you throw up a page that tells a little about what logic is used, what you check, where you get feeds from and how often, so that people can evaluate the differences between checkmy.net, phas, IRU and MYAsn? --Heather > >> >> - S >> >> -----Original Message----- >> From: Gadi Evron [mailto:ge at linuxbox.org] >> Sent: Friday, September 12, 2008 3:13 PM >> To: Kevin Oberman >> Cc: nanog at merit.edu >> Subject: Re: community real-time BGP hijack notification service >> >> On Fri, 12 Sep 2008, Kevin Oberman wrote: >>> Looks interesting, but it only takes a fairly short list of ASNs for a >>> prefix. For our big CIDR blocks, we have WAY too many ASNs to enter them >>> all, so it's pretty useless for me. I need to be able to enter at very >>> least a dozen ASes and I suspect may folks have a LOT more then that. >> >> I am sure we can fix that, Thanks for the comment! >> >>> For now, I'll enter some shorter pieces from the block, but I'm most >>> concerned with the pieces that are not currently assigned, so are >>> available for hijack. I have added the larger, unassigned blocks. I'll >>> start adding assigned bits and pieces as well as unassigned pieces, but >>> being able to put all valid origin ASes in the list for the full blocks >>> would be a lot nicer. >> >> Please let us know if you encounter any issues. >> >> >>> -- >>> 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 ge at linuxbox.org Fri Sep 12 18:37:23 2008 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 12 Sep 2008 18:37:23 -0500 (CDT) Subject: community real-time BGP hijack notification service In-Reply-To: <48CAEBF5.3080408@verizonbusiness.com> References: <20080912184350.F13D04500F@ptavv.es.net> <982D8D05B6407A49AD506E6C3AC8E7D6BD9A9DC584@caralain.haven.nynaeve.net> <48CAEBF5.3080408@verizonbusiness.com> Message-ID: On Fri, 12 Sep 2008, Heather Schiller wrote: > Gadi Evron wrote: >> On Fri, 12 Sep 2008, Skywing wrote: >>> It might be useful to have an option to generate an example alert mail for >>> purposes of setting up necessary mail processing rules and that sort. >>> Just a thought. >> >> Good point. Any suggestions from folks here on how they would like it to be >> built? >> > > Could you throw up a page that tells a little about what logic is used, what > you check, where you get feeds from and how often, so that people can > evaluate the differences between checkmy.net, phas, IRU and MYAsn? > > --Heather I don't see why not. But whilw we take this very seriously and so release only when a phase is done, it is a free-time based project. Therefore, while we will definitely do so... I can't commit it will be very soon. Much like other coders, while we appreciate documentation.. being very busy theorizing on what we already did will take some motivational coffee or a free evening. Comparing ourselves to other services... well, maybe some magazine will run a comperative testing. :) Gadi. > >> >>> >>> - S >>> >>> -----Original Message----- >>> From: Gadi Evron [mailto:ge at linuxbox.org] >>> Sent: Friday, September 12, 2008 3:13 PM >>> To: Kevin Oberman >>> Cc: nanog at merit.edu >>> Subject: Re: community real-time BGP hijack notification service >>> >>> On Fri, 12 Sep 2008, Kevin Oberman wrote: >>>> Looks interesting, but it only takes a fairly short list of ASNs for a >>>> prefix. For our big CIDR blocks, we have WAY too many ASNs to enter them >>>> all, so it's pretty useless for me. I need to be able to enter at very >>>> least a dozen ASes and I suspect may folks have a LOT more then that. >>> >>> I am sure we can fix that, Thanks for the comment! >>> >>>> For now, I'll enter some shorter pieces from the block, but I'm most >>>> concerned with the pieces that are not currently assigned, so are >>>> available for hijack. I have added the larger, unassigned blocks. I'll >>>> start adding assigned bits and pieces as well as unassigned pieces, but >>>> being able to put all valid origin ASes in the list for the full blocks >>>> would be a lot nicer. >>> >>> Please let us know if you encounter any issues. >>> >>> >>>> -- >>>> 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 Skywing at valhallalegends.com Fri Sep 12 19:41:14 2008 From: Skywing at valhallalegends.com (Skywing) Date: Fri, 12 Sep 2008 19:41:14 -0500 Subject: community real-time BGP hijack notification service In-Reply-To: References: <20080912184350.F13D04500F@ptavv.es.net> <982D8D05B6407A49AD506E6C3AC8E7D6BD9A9DC584@caralain.haven.nynaeve.net> <48CAC21A.1080807@gmail.com> Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6BD9A9DC588@caralain.haven.nynaeve.net> Ah, both reasons really; setup mail flow rules, verify mail delivery, and create appropriate whitelist entries if need be to make sure that notifications tend not to mysteriously vanish. All general things that I like to do for any new mail-based monitoring system. - S -----Original Message----- From: Gadi Evron [mailto:ge at linuxbox.org] Sent: Friday, September 12, 2008 3:50 PM To: Andrew Fried Cc: Skywing; Kevin Oberman; nanog at merit.edu Subject: Re: community real-time BGP hijack notification service On Fri, 12 Sep 2008, Andrew Fried wrote: > Mail being what it is today, testing message delivery is an excellent > idea. I'll implement that feature this weekend. I think he meant he wants to be able to get an example alert to his inbox on registration/on request so he can special filters which can wake him up. Gadi. > Andy > > Skywing wrote: >> It might be useful to have an option to generate an example alert mail for purposes of setting up necessary mail processing rules and that sort. Just a thought. >> >> - S >> >> -----Original Message----- >> From: Gadi Evron [mailto:ge at linuxbox.org] >> Sent: Friday, September 12, 2008 3:13 PM >> To: Kevin Oberman >> Cc: nanog at merit.edu >> Subject: Re: community real-time BGP hijack notification service >> >> On Fri, 12 Sep 2008, Kevin Oberman wrote: >> >>> Looks interesting, but it only takes a fairly short list of ASNs for a >>> prefix. For our big CIDR blocks, we have WAY too many ASNs to enter them >>> all, so it's pretty useless for me. I need to be able to enter at very >>> least a dozen ASes and I suspect may folks have a LOT more then that. >>> >> >> I am sure we can fix that, Thanks for the comment! >> >> >>> For now, I'll enter some shorter pieces from the block, but I'm most >>> concerned with the pieces that are not currently assigned, so are >>> available for hijack. I have added the larger, unassigned blocks. I'll >>> start adding assigned bits and pieces as well as unassigned pieces, but >>> being able to put all valid origin ASes in the list for the full blocks >>> would be a lot nicer. >>> >> >> Please let us know if you encounter any issues. >> >> >> >>> -- >>> 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 nonobvious at gmail.com Fri Sep 12 21:19:03 2008 From: nonobvious at gmail.com (Bill Stewart) Date: Fri, 12 Sep 2008 19:19:03 -0700 Subject: ingress SMTP In-Reply-To: <86ljxyj3fr.fsf@seastrom.com> References: <20080903151617.A14277808@relayer.avian.org> <48BEB3C3.1070600@gravityfree.com> <20080903161400.GI8979@cgi.jachomes.com> <48BEBDF4.9040109@mtcc.com> <20080903164941.GL8979@cgi.jachomes.com> <20080903190015.GS8979@cgi.jachomes.com> <48C8646A.3040207@bogus.com> <86ljxyj3fr.fsf@seastrom.com> Message-ID: <18a5e7cb0809121919k28af830epd8a4271290d861b5@mail.gmail.com> Hi, Hobbit - we met back in the late 80s / early 90s at various New Jersey things such as Trenton Computer Fair, but you probably don't remember me; Tigger says hi as well... "Be Liberal in what you accept, be conservative in what you send, and be really really clear in your error messages, except occasionally if you're lying to spammers." IMHO, selling somebody connectivity that blocks various ports isn't selling them Internet Service, it's selling them Walled Garden Couch-Potato Service. For many people that's ok, and if they're sending traffic on Port 25 it's only because some zombieware has taken over their PC, as opposed to because they're actually trying to send it. But the old PC on my desk upstairs has about 2500 times as much CPU and 500 times as much disk space as the Vaxen that I used to run email for a department of 30 people, and the network connection is about 300 times as fast, and there's no particular reason that it shouldn't have full end-to-end Internet presence like anybody's commercial mail server. That's different from 15 years ago when I only had dialup at home, because dialup wasn't really a full-time process, and sending mail was sufficiently unreliable that it made sense to run a dumb client at home that talked to a full-time smart host that knew how to queue messages and retry on failure. Blocking port 25 has become popular, not only with walled-garden connectivity services that are really scared of their customers running their own servers (e.g. most cable modem companies), but also with other ISPs that don't want to deal with the problems of having customers who are spamming (whether deliberate or zombified.) So anybody buying something lower-priced than a T1 typically needs to have a mail client or mail transfer agent that can use other ports, unless they want to trust their ISP's mail service or use webmail. And also obviously if you're running an outbound mail relay smarthost for your clients you need to accept mail from known people on the various authenticated ports in case they're stuck behind a randomly misbehaving ISP, and you should also support encrypted SMTP in general. In some sense, anything positive you an accomplish by blocking Port 25 you can also accomplish by leaving the port open and advertising the IP address on one of the dynamic / home broadband / etc. block lists, which leaves recipients free to whitelist or blacklist your users. And you can certainly provide better service to your customers by redirecting Port 25 connections to an SMTP server that returns "550 We block Port 25 - see www.example.net/faq/port25blocking" or some similarly useful message as opposed to just dropping the packets. I've toned down my vehemence about the blocking issue a bit - there's enough zombieware out there that I don't object strongly to an ISP that has it blocked by default but makes it easy for humans to enable. -- ---- Thanks; Bill Stewart Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From blakjak at blakjak.net Fri Sep 12 22:16:55 2008 From: blakjak at blakjak.net (Mark Foster) Date: Sat, 13 Sep 2008 15:16:55 +1200 (NZST) Subject: ingress SMTP In-Reply-To: <18a5e7cb0809121919k28af830epd8a4271290d861b5@mail.gmail.com> References: <20080903151617.A14277808@relayer.avian.org> <48BEB3C3.1070600@gravityfree.com> <20080903161400.GI8979@cgi.jachomes.com> <48BEBDF4.9040109@mtcc.com> <20080903164941.GL8979@cgi.jachomes.com> <20080903190015.GS8979@cgi.jachomes.com> <48C8646A.3040207@bogus.com> <86ljxyj3fr.fsf@seastrom.com> <18a5e7cb0809121919k28af830epd8a4271290d861b5@mail.gmail.com> Message-ID: > Blocking port 25 has become popular, not only with > walled-garden connectivity services that are really scared of their > customers running their own servers (e.g. most cable modem companies), > but also with other ISPs that don't want to deal with the problems > of having customers who are spamming (whether deliberate or zombified.) > So anybody buying something lower-priced than a T1 typically needs to > have a mail client or mail transfer agent that can use other ports, > unless they want to trust their ISP's mail service or use webmail. What proportion of an ISP's customers genuinely need the ability to talk to external hosts on 25/tcp? I mean really? We're talking about home users who can use their home ISP SMTP service and it'll meet their needs. Agree that there should be a mechanism to opt out, but smart organisations will offer alternative, authenticated services to address any requirement for direct SMTP (except perhaps for situations where you actually intend to run a mail server at home.) > In some sense, anything positive you an accomplish by blocking Port 25 > you can also accomplish by leaving the port open and advertising the IP > address > on one of the dynamic / home broadband / etc. block lists, > which leaves recipients free to whitelist or blacklist your users. > And you can certainly provide better service to your customers by > redirecting Port 25 connections to an SMTP server that returns > "550 We block Port 25 - see www.example.net/faq/port25blocking" > or some similarly useful message as opposed to just dropping the packets. I concur with the latter, but then again, if it's well publicised and clear from the get-go that external pot 25 is not a service offered, it should be no big deal. I do disagree that advertising the IP on blocklists serves the same purpose, because it pushes responsibility to a third party (ala ISP is waving its hands in the air and saying 'it's not my problem, we're just a means of access to the cloud', and suddenly third party outfits get a whole bunch more clout than is necessary - and noise levels on the internet go up and/or junk volumes go up. (Wonder how much spam the port-25-blockers actually stop?) Would seem easier and a whole bunch more flexible for ISPs to manage their own turf, as it were, third party blocklists are a little on the ugly side. (False Positives are very hard to get dealt with, from experience.) > I've toned down my vehemence about the blocking issue a bit - > there's enough zombieware out there that I don't object strongly to an ISP > that has it blocked by default but makes it easy for humans to enable. Fair enough. I think there's probably agreement on this point, but I would also make the point that the only legitimate reason to enable 25/tcp outbound to external hosts should be to run a mail server. SMTP-Auth for private use, for example, shouldn't be on 25. Mark. From mmc at internode.com.au Sat Sep 13 00:41:02 2008 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Sat, 13 Sep 2008 15:11:02 +0930 Subject: ingress SMTP In-Reply-To: <18a5e7cb0809121919k28af830epd8a4271290d861b5@mail.gmail.com> References: <20080903151617.A14277808@relayer.avian.org> <48BEB3C3.1070600@gravityfree.com> <20080903161400.GI8979@cgi.jachomes.com> <48BEBDF4.9040109@mtcc.com> <20080903164941.GL8979@cgi.jachomes.com> <20080903190015.GS8979@cgi.jachomes.com> <48C8646A.3040207@bogus.com> <86ljxyj3fr.fsf@seastrom.com> <18a5e7cb0809121919k28af830epd8a4271290d861b5@mail.gmail.com> Message-ID: <48CB526E.2030309@internode.com.au> Hi Bill, Bill Stewart wrote: > In some sense, anything positive you an accomplish by blocking Port 25 > you can also accomplish by leaving the port open and advertising the IP > address > on one of the dynamic / home broadband / etc. block lists, > which leaves recipients free to whitelist or blacklist your users. > Except that this tends to lead to a worse situation for people like yourself who wish to run a mailserver - because ultimately you'll have to resort to using an ISP's forwarder anyway because there will be more spam from the IP ranges you're in leaving to the wide world, thus a worse reputation, and so more blocking. ie. by blocking outbound SMTP by default and getting customers to use our mail cluster their email is more likely to arrive and not be dropped as coming from a potential spam source. > I've toned down my vehemence about the blocking issue a bit - > there's enough zombieware out there that I don't object strongly to an ISP > that has it blocked by default but makes it easy for humans to enable. > That's what we do - by default most customers have a small ACL applied which protects them from traffic from various windows ports, ensures SMTP goes via our mail cluster etc. Having customers send mail out via us is actually better because we do spam checking and can alert customers to their machines being compromised etc (or at least customers can look at their status themselves). But, customers can easily turn the filtering off via the portal we have. We have no issues with customers running servers - most people don't, and those who do value the ability to do so. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc at internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 From mmc at internode.com.au Sat Sep 13 00:48:25 2008 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Sat, 13 Sep 2008 15:18:25 +0930 Subject: community real-time BGP hijack notification service In-Reply-To: <48CA7BD6.1090507@pnzone.net> References: <6C848BB6-7C98-4BF4-93B9-01CBA32A0FC6@nosignal.org> <48CA7BD6.1090507@pnzone.net> Message-ID: <48CB5429.7000908@internode.com.au> Arnaud de Prelle wrote: > I think that most of us (me included) are already using it but the > problem is that they don't have BGP collectors everywhere in the world. > This is in fact a generic issue for BGP monitoring. > In this case it's very important to have a lot of collectors broadly distributed listening in many ASes. For example: If I know there are two BGP collectors driving this service, and they're in, say, AS701 and AS1239, then if I wanted to do a partial hijack (which might be good enough for my evil purposes) then I could advertise a path which had those ASes stuffed in it and prevent downstream collectors in AS701 and AS1239 from learning the hijack path. > So the more we get the best it is and that's why I'll be using Gadi's > BGP monitoring tool (and any other that might come) in parallel with the > one provided by the RIPE. > Hear hear for Gadi and others offering these tools. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks From nanog at daork.net Sat Sep 13 01:30:25 2008 From: nanog at daork.net (Nathan Ward) Date: Sat, 13 Sep 2008 18:30:25 +1200 Subject: community real-time BGP hijack notification service In-Reply-To: <48CB5429.7000908@internode.com.au> References: <6C848BB6-7C98-4BF4-93B9-01CBA32A0FC6@nosignal.org> <48CA7BD6.1090507@pnzone.net> <48CB5429.7000908@internode.com.au> Message-ID: <54127B0D-A21D-436B-B502-CC5A41A80ED0@daork.net> On 13/09/2008, at 5:48 PM, Matthew Moyle-Croft wrote: > Arnaud de Prelle wrote: >> I think that most of us (me included) are already using it but the >> problem is that they don't have BGP collectors everywhere in the >> world. >> This is in fact a generic issue for BGP monitoring. >> > In this case it's very important to have a lot of collectors broadly > distributed listening in many ASes. > > For example: > > If I know there are two BGP collectors driving this service, and > they're in, say, AS701 and AS1239, then if I wanted to do a partial > hijack (which might be good enough for my evil purposes) then I > could advertise a path which had those ASes stuffed in it and > prevent downstream collectors in AS701 and AS1239 from learning the > hijack path. Note that the attack becomes less and less effective if you're path stuffing ASes, as it will be preferred by fewer and fewer networks. Put collection points in say 10 networks, and the attack becomes pretty useless. Unless of course you are announcing a more specific prefix than the authentic one. -- Nathan Ward From mmc at internode.com.au Sat Sep 13 02:15:09 2008 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Sat, 13 Sep 2008 16:45:09 +0930 Subject: community real-time BGP hijack notification service In-Reply-To: <54127B0D-A21D-436B-B502-CC5A41A80ED0@daork.net> References: <6C848BB6-7C98-4BF4-93B9-01CBA32A0FC6@nosignal.org> <48CA7BD6.1090507@pnzone.net> <48CB5429.7000908@internode.com.au> <54127B0D-A21D-436B-B502-CC5A41A80ED0@daork.net> Message-ID: <48CB687D.1090008@internode.com.au> Nathan Ward wrote: > On 13/09/2008, at 5:48 PM, Matthew Moyle-Croft wrote: > >> Arnaud de Prelle wrote: >>> I think that most of us (me included) are already using it but the >>> problem is that they don't have BGP collectors everywhere in the world. >>> This is in fact a generic issue for BGP monitoring. >>> >> In this case it's very important to have a lot of collectors broadly >> distributed listening in many ASes. >> >> For example: >> >> If I know there are two BGP collectors driving this service, and >> they're in, say, AS701 and AS1239, then if I wanted to do a partial >> hijack (which might be good enough for my evil purposes) then I could >> advertise a path which had those ASes stuffed in it and prevent >> downstream collectors in AS701 and AS1239 from learning the hijack path. > > > Note that the attack becomes less and less effective if you're path > stuffing ASes, as it will be preferred by fewer and fewer networks. > Put collection points in say 10 networks, and the attack becomes > pretty useless. > Unless of course you are announcing a more specific prefix than the > authentic one. Absolutely - but it depends how wide you want the hijack - a global one is very obvious, but you can see that a very narrow one of some sites it might be harder (take longer) to detect and live longer. ie. If I just wanted to disrupt a website to a country or region for political reasons or just to get the ad revenue for a small amount of time, then it might be acceptable to limit the scale in order to evade detection. I'm not saying this is the end of the world, just reenforcing that widely distributed BGP monitors are necessary for detection. It might be that various projects which have these distributed tools etc can help by becoming feeds for these kinds of notification projects. MMC > > -- > Nathan Ward > > > > > From randy at psg.com Sat Sep 13 02:21:02 2008 From: randy at psg.com (Randy Bush) Date: Sat, 13 Sep 2008 16:21:02 +0900 Subject: community real-time BGP hijack notification service In-Reply-To: <54127B0D-A21D-436B-B502-CC5A41A80ED0@daork.net> References: <6C848BB6-7C98-4BF4-93B9-01CBA32A0FC6@nosignal.org> <48CA7BD6.1090507@pnzone.net> <48CB5429.7000908@internode.com.au> <54127B0D-A21D-436B-B502-CC5A41A80ED0@daork.net> Message-ID: <48CB69DE.9090504@psg.com> i am occasionally asked if there have been real bgp attacks (not slips). the answer is, of course yes, but there are none which can be publicly described. when bucks and embarrassment are involved, security through obscurity seems to rule. but tony and alex did us an enormous favor by publicly conducting such an attack, see http://www.merit.edu/mail.archives/nanog/msg10357.html so, what i want to know is which, if any of the tools being discussed on this thread *actually* did or could detect and/or mitigate the tony/alex defcon attack. i appreciate the dozens of tools that detect and mitigate finger or brain fumbles. but those are not where the black hats are gonna go to make the big bucks. randy From nanog at daork.net Sat Sep 13 02:58:21 2008 From: nanog at daork.net (Nathan Ward) Date: Sat, 13 Sep 2008 19:58:21 +1200 Subject: community real-time BGP hijack notification service In-Reply-To: <48CB69DE.9090504@psg.com> References: <6C848BB6-7C98-4BF4-93B9-01CBA32A0FC6@nosignal.org> <48CA7BD6.1090507@pnzone.net> <48CB5429.7000908@internode.com.au> <54127B0D-A21D-436B-B502-CC5A41A80ED0@daork.net> <48CB69DE.9090504@psg.com> Message-ID: On 13/09/2008, at 7:21 PM, Randy Bush wrote: > i am occasionally asked if there have been real bgp attacks (not > slips). > the answer is, of course yes, but there are none which can be publicly > described. when bucks and embarrassment are involved, security > through > obscurity seems to rule. > > but tony and alex did us an enormous favor by publicly conducting such > an attack, see http://www.merit.edu/mail.archives/nanog/msg10357.html > > so, what i want to know is which, if any of the tools being > discussed on > this thread *actually* did or could detect and/or mitigate the tony/ > alex > defcon attack. > > i appreciate the dozens of tools that detect and mitigate finger or > brain fumbles. but those are not where the black hats are gonna go to > make the big bucks. Yep, that was my point before. My concern is that unless there is big bold text saying that it's not a solution, and then reference to longer optional text for those that care about why, people will get a false sense of security. -- Nathan Ward From md at Linux.IT Sat Sep 13 05:11:25 2008 From: md at Linux.IT (Marco d'Itri) Date: Sat, 13 Sep 2008 12:11:25 +0200 Subject: New Intercage upstream In-Reply-To: <20080913022610.GD31310@biggins.networkcommand.com> References: <6BCAB7B989C2EA4AAD36652C14D4FB4551CEAD@FHDP1CCMXCV02.us.one.verizon.com> <200809121424.34050.lowen@pari.edu> <27426.1221249301@turing-police.cc.vt.edu> <20080913022610.GD31310@biggins.networkcommand.com> Message-ID: <20080913101125.GA8120@bongo.bofh.it> On Sep 13, "Jon O." wrote: > Looks like this might be somewhat bulletproof, check the other sites off this "AS" > http://www.robtex.com/dns/pacificinternetexchange.net.html#a2 It may be, yes. Look at what else this AS is announcing: http://www.spamhaus.org/sbl/sbl.lasso?query=SBL36453 (cernel/esthost) http://www.spamhaus.org/sbl/sbl.lasso?query=SBL36702 (the infamous UkrTeleGroup network) http://www.spamhaus.org/sbl/sbl.lasso?query=SBL53319 (inhoster) Interested parties can consult http://www.bofh.it/~md/drop-stats.txt (randomly updated, I am still looking for a permanent home for it) for a detailed list of who is announcing the networks listed in SBL DROP, what else they announce and who is providing transit to the ASes announcing them. The code used to generate it is available on request. Hint: there is not just Intercage. -- ciao, Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From bobince at gmail.com Sat Sep 13 06:59:28 2008 From: bobince at gmail.com (Andrew Clover) Date: Sat, 13 Sep 2008 13:59:28 +0200 Subject: New Intercage upstream Message-ID: Marco d'Itri wrote: > Look at what else this AS is announcing: Cernel, UkrTeleGroup and Inhoster are all aliases of Esthost. These are their blocks that are physically operated by Intercage, so it's not surprising they're to be found together. PIE is another colo operation housed at the same facility as Intercage (200 Paul Avenue, SF). Their focus appears to be hosting Japanese sites in the US (colo inside Japan itself has historically been quite expensive). They may well be unaware of the nature of their datacentre-neighbours. -- From lowen at pari.edu Sat Sep 13 10:06:32 2008 From: lowen at pari.edu (Lamar Owen) Date: Sat, 13 Sep 2008 11:06:32 -0400 Subject: New Intercage upstream In-Reply-To: <20080913101125.GA8120@bongo.bofh.it> References: <6BCAB7B989C2EA4AAD36652C14D4FB4551CEAD@FHDP1CCMXCV02.us.one.verizon.com> Message-ID: <200809131106.32819.lowen@pari.edu> On Saturday 13 September 2008 06:11:25 Marco d'Itri wrote: > Interested parties can consult http://www.bofh.it/~md/drop-stats.txt > (randomly updated, I am still looking for a permanent home for it) > for a detailed list of who is announcing the networks listed in SBL > DROP, what else they announce and who is providing transit to the ASes > announcing them. The code used to generate it is available on request. Hmmm. Callout to Randy Bush: tools like this and the techniques to use them are tailor-made for cluepon, no? From frnkblk at iname.com Sat Sep 13 10:43:29 2008 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 13 Sep 2008 10:43:29 -0500 Subject: Identifying when netblocks have been assigned Message-ID: Perhaps there's no answer to this, or it's obvious and I ought to know. How can I find out when ARIN or the applicable registry has assigned a block to a certain organization, and I don't know the block, just the organization. If that's not possible, is there a site/way that has a timeline for the first time a certain AS announced a block? Frank From jake at nobistech.net Sat Sep 13 10:49:37 2008 From: jake at nobistech.net (Jake Mertel) Date: Sat, 13 Sep 2008 10:49:37 -0500 Subject: Identifying when netblocks have been assigned In-Reply-To: References: Message-ID: <48CBE111.5020409@nobistech.net> Frank, Add the > operator in front of the organizations ARIN ID when you do your WHOIS query and it will show all of the resources allocated to that organization. -- Regards, Jake Mertel Nobis Technology Group, L.L.C. Frank Bulk wrote: > Perhaps there's no answer to this, or it's obvious and I ought to know. > > How can I find out when ARIN or the applicable registry has assigned a block > to a certain organization, and I don't know the block, just the > organization. > If that's not possible, is there a site/way that has a timeline for the > first time a certain AS announced a block? > > Frank > > > From ge at linuxbox.org Sat Sep 13 10:50:59 2008 From: ge at linuxbox.org (Gadi Evron) Date: Sat, 13 Sep 2008 10:50:59 -0500 (CDT) Subject: New Intercage upstream In-Reply-To: References: Message-ID: On Sat, 13 Sep 2008, Andrew Clover wrote: > Marco d'Itri wrote: > >> Look at what else this AS is announcing: > > Cernel, UkrTeleGroup and Inhoster are all aliases of Esthost. These > are their blocks that are physically operated by Intercage, so it's > not surprising they're to be found together. > > PIE is another colo operation housed at the same facility as Intercage > (200 Paul Avenue, SF). Their focus appears to be hosting Japanese > sites in the US (colo inside Japan itself has historically been quite > expensive). They may well be unaware of the nature of their > datacentre-neighbours. I don't know if this AS is evil, and quite possibly it isn't. However, it has every intention of keeping Atrivo / Intercage as a slient. Perhaps we need to talk to their transit providers, after all, it is the exact same network just somewhere else. No changes. Gadi. From woody at pch.net Sat Sep 13 12:44:31 2008 From: woody at pch.net (Bill Woodcock) Date: Sat, 13 Sep 2008 10:44:31 -0700 (PDT) Subject: Identifying when netblocks have been assigned In-Reply-To: References: Message-ID: On Sat, 13 Sep 2008, Frank Bulk wrote: > Perhaps there's no answer to this, or it's obvious and I ought to know. > How can I find out when ARIN or the applicable registry has assigned a block > to a certain organization, and I don't know the block, just the > organization. > If that's not possible, is there a site/way that has a timeline for the > first time a certain AS announced a block? Those are both very simple reports to run from PCH's existing databases and data-feeds. The only tricky part is how you specify the organization name... Are you planning on using the RIR OrgID, or an exact-match on the organization name, or a substring or regex match? Or would you like something that tries to map through origin AS? -Bill From woody at pch.net Sat Sep 13 12:47:04 2008 From: woody at pch.net (Bill Woodcock) Date: Sat, 13 Sep 2008 10:47:04 -0700 (PDT) Subject: Identifying when netblocks have been assigned In-Reply-To: References: Message-ID: On Sat, 13 Sep 2008, Bill Woodcock wrote: > Those are both very simple reports to run from PCH's existing databases > and data-feeds. By that, I mean that they could be run daily, and specific results emailed to people who were interested in following the allocation patterns for specific organizations, any time there was a match. -Bill From frnkblk at iname.com Sat Sep 13 12:52:17 2008 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 13 Sep 2008 12:52:17 -0500 Subject: Identifying when netblocks have been assigned In-Reply-To: <48CBE111.5020409@nobistech.net> References: <48CBE111.5020409@nobistech.net> Message-ID: When I do that it lists the organization's AS, but not any netblocks associated with that AS. Frank -----Original Message----- From: Jake Mertel [mailto:jake at nobistech.net] Sent: Saturday, September 13, 2008 10:50 AM To: Frank Bulk Cc: nanog at nanog.org Subject: Re: Identifying when netblocks have been assigned Frank, Add the > operator in front of the organizations ARIN ID when you do your WHOIS query and it will show all of the resources allocated to that organization. -- Regards, Jake Mertel Nobis Technology Group, L.L.C. Frank Bulk wrote: > Perhaps there's no answer to this, or it's obvious and I ought to know. > > How can I find out when ARIN or the applicable registry has assigned a block > to a certain organization, and I don't know the block, just the > organization. > If that's not possible, is there a site/way that has a timeline for the > first time a certain AS announced a block? > > Frank > > > From woody at pch.net Sat Sep 13 12:56:33 2008 From: woody at pch.net (Bill Woodcock) Date: Sat, 13 Sep 2008 10:56:33 -0700 (PDT) Subject: Identifying when netblocks have been assigned In-Reply-To: References: Message-ID: On Sat, 13 Sep 2008, Bill Woodcock wrote: > By that, I mean that they could be run daily, and specific results emailed > to people who were interested in following the allocation patterns for > specific organizations, any time there was a match. Following up on my own post for the second time tells me that I'm posting too early in the morning, or without the recommended seven-second broadcast delay between brain and fingers, but... My colleagues have reminded me that we already built this system two years ago, and it produces an RSS feed, rather than email results. Also, that we hadn't done as much as we should do to provide filtering tools to narrow down the results. So, two questions for the community: 1) Would people prefer to receive these results via email, or RSS, or some other mechanism? 2) What would the structure of the query or filter look like, ideally? What key would you like to be querying on, and how would you like the results focused? -Bill From frnkblk at iname.com Sat Sep 13 12:59:42 2008 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 13 Sep 2008 12:59:42 -0500 Subject: Identifying when netblocks have been assigned In-Reply-To: References: Message-ID: Ok, so not so simple. =) I'm not familiar with the layout of PCH's data (I did find some .gz files, so I presume that's the data that's gathered on a daily basis), but if I was, I would have to take the divide-and-conquer approach for a certain AS to find out when a block was first announced. I'm guessing that I would have to do the hard work. Perhaps Renesys is already doing this? (but for a fee). Regards, Frank -----Original Message----- From: Bill Woodcock [mailto:woody at pch.net] Sent: Saturday, September 13, 2008 12:47 PM To: Frank Bulk Cc: jonny at pch.net; Vijay Kumar Adhikari; nanog at nanog.org Subject: Re: Identifying when netblocks have been assigned On Sat, 13 Sep 2008, Bill Woodcock wrote: > Those are both very simple reports to run from PCH's existing databases > and data-feeds. By that, I mean that they could be run daily, and specific results emailed to people who were interested in following the allocation patterns for specific organizations, any time there was a match. -Bill From frnkblk at iname.com Sat Sep 13 13:06:39 2008 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 13 Sep 2008 13:06:39 -0500 Subject: Identifying when netblocks have been assigned In-Reply-To: References: Message-ID: No problem, I had my coffee 2 hours ago. 1) I would prefer e-mail, and ideally on-demand querying from a web form. And even more pie in the sky, something like Google Trends (i.e. http://www.google.com/trends?q=hurricane+katrina&ctab=0&geo=all&date=all) that shows the quantity of IP addresses that are being advertised over time. 2) Basically I would sign up for certain AS' and be informed when new blocks are added, or when blocks stop being advertised (for a full 24-hour period, I don't think there's value in seeing when it's withdrawn and re-advertised in one day). There might be some people that want to know when a block is first advertised, but that's less likely unless they're tracking the de-BOGON announcements. Regards, Frank -----Original Message----- From: Bill Woodcock [mailto:woody at pch.net] Sent: Saturday, September 13, 2008 12:57 PM To: Frank Bulk Cc: jonny at pch.net; Vijay Kumar Adhikari; nanog at nanog.org Subject: Re: Identifying when netblocks have been assigned On Sat, 13 Sep 2008, Bill Woodcock wrote: > By that, I mean that they could be run daily, and specific results emailed > to people who were interested in following the allocation patterns for > specific organizations, any time there was a match. Following up on my own post for the second time tells me that I'm posting too early in the morning, or without the recommended seven-second broadcast delay between brain and fingers, but... My colleagues have reminded me that we already built this system two years ago, and it produces an RSS feed, rather than email results. Also, that we hadn't done as much as we should do to provide filtering tools to narrow down the results. So, two questions for the community: 1) Would people prefer to receive these results via email, or RSS, or some other mechanism? 2) What would the structure of the query or filter look like, ideally? What key would you like to be querying on, and how would you like the results focused? -Bill From frnkblk at iname.com Sat Sep 13 13:08:34 2008 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 13 Sep 2008 13:08:34 -0500 Subject: ingress SMTP In-Reply-To: <48CB526E.2030309@internode.com.au> References: <20080903151617.A14277808@relayer.avian.org> <48BEB3C3.1070600@gravityfree.com> <20080903161400.GI8979@cgi.jachomes.com> <48BEBDF4.9040109@mtcc.com> <20080903164941.GL8979@cgi.jachomes.com> <20080903190015.GS8979@cgi.jachomes.com> <48C8646A.3040207@bogus.com> <86ljxyj3fr.fsf@seastrom.com> <18a5e7cb0809121919k28af830epd8a4271290d861b5@mail.gmail.com> <48CB526E.2030309@internode.com.au> Message-ID: How do you alert mail server operators who are smarthosting their e-mail through you that their outbound messages contain spam? Frank -----Original Message----- From: Matthew Moyle-Croft [mailto:mmc at internode.com.au] Sent: Saturday, September 13, 2008 12:41 AM To: Bill Stewart Cc: nanog at nanog.org Subject: Re: ingress SMTP Hi Bill, Bill Stewart wrote: > In some sense, anything positive you an accomplish by blocking Port 25 > you can also accomplish by leaving the port open and advertising the IP > address > on one of the dynamic / home broadband / etc. block lists, > which leaves recipients free to whitelist or blacklist your users. > Except that this tends to lead to a worse situation for people like yourself who wish to run a mailserver - because ultimately you'll have to resort to using an ISP's forwarder anyway because there will be more spam from the IP ranges you're in leaving to the wide world, thus a worse reputation, and so more blocking. ie. by blocking outbound SMTP by default and getting customers to use our mail cluster their email is more likely to arrive and not be dropped as coming from a potential spam source. > I've toned down my vehemence about the blocking issue a bit - > there's enough zombieware out there that I don't object strongly to an ISP > that has it blocked by default but makes it easy for humans to enable. > That's what we do - by default most customers have a small ACL applied which protects them from traffic from various windows ports, ensures SMTP goes via our mail cluster etc. Having customers send mail out via us is actually better because we do spam checking and can alert customers to their machines being compromised etc (or at least customers can look at their status themselves). But, customers can easily turn the filtering off via the portal we have. We have no issues with customers running servers - most people don't, and those who do value the ability to do so. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc at internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 From nicotine at warningg.com Sat Sep 13 13:26:18 2008 From: nicotine at warningg.com (Brandon Ewing) Date: Sat, 13 Sep 2008 13:26:18 -0500 Subject: Cisco uRPF failures In-Reply-To: <20080911171128.GA5283@mx.ytti.net> References: <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com> <00c401c9072b$f46a38c0$dd3eaa40$@com> <007401c90e25$6eaf2280$4c0d6780$@com> <6bb5f5b10809031906m67c18854nb4fe7260ad3e153@mail.gmail.com> <5188BB8F-8EFC-4FCA-BA9F-E36E6C3CEB81@netconsonance.com> <20080908085510.GA27179@mx.ytti.net> <20080911171128.GA5283@mx.ytti.net> Message-ID: <20080913182618.GA29660@biological.warningg.com> On Thu, Sep 11, 2008 at 08:11:28PM +0300, Saku Ytti wrote: > > Sound like these shops are using 3550 as router, which is common for > smaller shops, especially in EU. And indeed, 3550 would not do uRPF. > (3560E does). > Are you sure? According to the IOS guide for 3560E/3750E, "ip verify" is still an unsupported interface command. I don't have a 3560E handy to test on, but I know that a non-E 3560 refuses it with a notice regarding how verification is not supported by hardware. http://tinyurl.com/5qbqzb -- Brandon From stephen at sprunk.org Sat Sep 13 14:12:19 2008 From: stephen at sprunk.org (Stephen Sprunk) Date: Sat, 13 Sep 2008 14:12:19 -0500 Subject: Identifying when netblocks have been assigned In-Reply-To: References: <48CBE111.5020409@nobistech.net> Message-ID: <48CC1093.9000404@sprunk.org> Frank Bulk wrote: > When I do that it lists the organization's AS, but not any netblocks > associated with that AS. > > Frank > > -----Original Message----- > From: Jake Mertel [mailto:jake at nobistech.net] > > Frank, > > Add the > operator in front of the organizations ARIN ID when you do > your WHOIS query and it will show all of the resources allocated to that > organization. > Keep in mind that the "> OrgID" trick only works for allocations or assignments made directly by ARIN; it won't necessarily show you everything that was SWIPed to them, since many SWIPs are not tagged with an OrgID. To find those, you have to search on the name of the customer and hope it shows up correctly in the CustName field. Also, many companies end up with lots of OrgIDs, and many of them may not have the correct current name due to M&A activity. Finding them all may take a while and isn't easily automated. S From saku+nanog at ytti.fi Sat Sep 13 15:00:31 2008 From: saku+nanog at ytti.fi (Saku Ytti) Date: Sat, 13 Sep 2008 23:00:31 +0300 Subject: Cisco uRPF failures In-Reply-To: <20080913182618.GA29660@biological.warningg.com> References: <00c401c9072b$f46a38c0$dd3eaa40$@com> <007401c90e25$6eaf2280$4c0d6780$@com> <6bb5f5b10809031906m67c18854nb4fe7260ad3e153@mail.gmail.com> <5188BB8F-8EFC-4FCA-BA9F-E36E6C3CEB81@netconsonance.com> <20080908085510.GA27179@mx.ytti.net> <20080911171128.GA5283@mx.ytti.net> <20080913182618.GA29660@biological.warningg.com> Message-ID: <20080913200031.GA15804@mx.ytti.net> On (2008-09-13 13:26 -0500), Brandon Ewing wrote: Hey Brandon, > Are you sure? According to the IOS guide for 3560E/3750E, "ip verify" is > still an unsupported interface command. I don't have a 3560E handy to test > on, but I know that a non-E 3560 refuses it with a notice regarding how > verification is not supported by hardware. To be honest I'm not sure. Feature-wise highlights what I've taken note of E series in 3560 is jumbo MTU support in L3 and uRPF in comparison to non E, apart from the obvious 10GE and PSU enhancements. While I haven't personally ran 3560E, I'm fairly confident that it's supported, in hardware (And software to turn it on). uRPF is mentioned here: http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps7078/product_data_sheet0900aecd805bac22.html Advanced Security ? Unicast RPF feature helps mitigate problems caused by the introduction of malformed or forged (spoofed) IP source addresses into a network by discarding IP packets that lack a verifiable IP source address. -- ++ytti From mmc at internode.com.au Sat Sep 13 17:39:04 2008 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Sun, 14 Sep 2008 08:09:04 +0930 Subject: ingress SMTP In-Reply-To: References: <20080903151617.A14277808@relayer.avian.org> <48BEB3C3.1070600@gravityfree.com> <20080903161400.GI8979@cgi.jachomes.com> <48BEBDF4.9040109@mtcc.com> <20080903164941.GL8979@cgi.jachomes.com> <20080903190015.GS8979@cgi.jachomes.com> <48C8646A.3040207@bogus.com> <86ljxyj3fr.fsf@seastrom.com> <18a5e7cb0809121919k28af830epd8a4271290d861b5@mail.gmail.com> <48CB526E.2030309@internode.com.au> Message-ID: <48CC4108.9090705@internode.com.au> Frank Bulk wrote: > How do you alert mail server operators who are smarthosting their e-mail > through you that their outbound messages contain spam? > Typically a ticket gets injected into helpdesk who then contact them via email or via a phone call depending on the situation. I don't think we've automated it as often these kinds of people don't react well or ignore it - so a human being needs to intervene and often give help. We also take measures such as rate limiting the amount of email they can send (kbps, msg per hour wise) to limit the damage. We offer a URL for customers that allows them to see their "spam" rating for their IPs (this includes if they're sending out viruses as well) - including a text only version (2 lines of text) so it can be easily parsed by machine if someone wanted to integrate it into their own checking. We try and have default settings that protect us and the users as much as possible, but allow people who (at least think they) know what they're doing to change them to be more open. Our general customer base tends to be biased towards the techy type who want this kind of thing. (We sponsor things like the Australian Systems Administrator's Guild etc) MMC > Frank > > -----Original Message----- > From: Matthew Moyle-Croft [mailto:mmc at internode.com.au] > Sent: Saturday, September 13, 2008 12:41 AM > To: Bill Stewart > Cc: nanog at nanog.org > Subject: Re: ingress SMTP > > Hi Bill, > > Bill Stewart wrote: > >> In some sense, anything positive you an accomplish by blocking Port 25 >> you can also accomplish by leaving the port open and advertising the IP >> address >> on one of the dynamic / home broadband / etc. block lists, >> which leaves recipients free to whitelist or blacklist your users. >> >> > Except that this tends to lead to a worse situation for people like > yourself who wish to run a mailserver - because ultimately you'll have > to resort to using an ISP's forwarder anyway because there will be more > spam from the IP ranges you're in leaving to the wide world, thus a > worse reputation, and so more blocking. > > ie. by blocking outbound SMTP by default and getting customers to use > our mail cluster their email is more likely to arrive and not be dropped > as coming from a potential spam source. > > >> I've toned down my vehemence about the blocking issue a bit - >> there's enough zombieware out there that I don't object strongly to an ISP >> that has it blocked by default but makes it easy for humans to enable. >> >> > That's what we do - by default most customers have a small ACL applied > which protects them from traffic from various windows ports, ensures > SMTP goes via our mail cluster etc. Having customers send mail out via > us is actually better because we do spam checking and can alert > customers to their machines being compromised etc (or at least customers > can look at their status themselves). But, customers can easily turn > the filtering off via the portal we have. > > We have no issues with customers running servers - most people don't, > and those who do value the ability to do so. > > MMC > > -- > Matthew Moyle-Croft - Internode/Agile - Networks > > > > > From ops.lists at gmail.com Sat Sep 13 20:38:59 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sun, 14 Sep 2008 07:08:59 +0530 Subject: ingress SMTP In-Reply-To: References: <20080903151617.A14277808@relayer.avian.org> <48BEBDF4.9040109@mtcc.com> <20080903164941.GL8979@cgi.jachomes.com> <20080903190015.GS8979@cgi.jachomes.com> <48C8646A.3040207@bogus.com> <86ljxyj3fr.fsf@seastrom.com> <18a5e7cb0809121919k28af830epd8a4271290d861b5@mail.gmail.com> <48CB526E.2030309@internode.com.au> Message-ID: On Sat, Sep 13, 2008 at 11:38 PM, Frank Bulk wrote: > How do you alert mail server operators who are smarthosting their e-mail > through you that their outbound messages contain spam? > > Frank If those are actual mailservers smarthosting and getting MX from you then you doubtless have quite a lot of reporting already set up. Have you seen what Messagelabs, MXLogic etc do? There's also feedback loops, ARF formatted, where users on those mailservers can report inbound spam to the filtering vendor. .. or was that a rhetorical question and am I missing something here? -- Suresh Ramasubramanian (ops.lists at gmail.com) From hobbit at avian.org Sat Sep 13 20:28:59 2008 From: hobbit at avian.org (*Hobbit*) Date: Sun, 14 Sep 2008 01:28:59 +0000 (GMT) Subject: ingress SMTP Message-ID: <20080914012859.85AAB7808@relayer.avian.org> > How do you alert mail server operators who are smarthosting their > e-mail through you that their outbound messages contain spam? You don't let them falsify their envelope or headers to contain fields utterly unrelated to your own infrastructure, for starters. They try it, their mail bounces. It's a very rare piece of spam that actually comes from who it says it comes from anymore. Do that before thinking about rate-limiting or any other fanciness, and you've likely licked 90% of the problem right there. A smarthost with a strong "sense of self" backed up by port-25 rules is exactly what I'm talking about, and if certain large providers ever *read* their abuse boxes they'd find the same advice from me in more than one instance followed by a clear example of why. _H* From mmc at internode.com.au Sat Sep 13 22:58:00 2008 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Sun, 14 Sep 2008 13:28:00 +0930 Subject: ingress SMTP In-Reply-To: <20080914012859.85AAB7808@relayer.avian.org> References: <20080914012859.85AAB7808@relayer.avian.org> Message-ID: <48CC8BC8.6030208@internode.com.au> *Hobbit* wrote: > > How do you alert mail server operators who are smarthosting their > > e-mail through you that their outbound messages contain spam? > > You don't let them falsify their envelope or headers to contain > fields utterly unrelated to your own infrastructure, for starters. > They try it, their mail bounces. It's a very rare piece of > spam that actually comes from who it says it comes from anymore. > Are you suggesting that only ISP domains should be allowed through? (eg. username at isp.net.au) If you're forcing people to use your mail servers as a smart host then you wouldn't be very popular ... MMC From frnkblk at iname.com Sun Sep 14 00:02:48 2008 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 14 Sep 2008 00:02:48 -0500 Subject: ingress SMTP In-Reply-To: References: <20080903151617.A14277808@relayer.avian.org> <48BEBDF4.9040109@mtcc.com> <20080903164941.GL8979@cgi.jachomes.com> <20080903190015.GS8979@cgi.jachomes.com> <48C8646A.3040207@bogus.com> <86ljxyj3fr.fsf@seastrom.com> <18a5e7cb0809121919k28af830epd8a4271290d861b5@mail.gmail.com> <48CB526E.2030309@internode.com.au> Message-ID: Apologies for not being more clear, because I see the responses going in tangents I hadn't expected. Most anti-spam products drop the connection or issue some kind of rejection message during the SMTP exchange. If the connection is dropped, the subscriber's MTA/MUA will likely try and try again until it reaches expiration time. For MS Exchange I think that's two or three days. For Outlook Express, that message just sits in the Outbox. If a rejection message was issued, hopefully the sender can interpret what the MUA is saying, or the MTA sends back an undeliverable. So, for service providers who require their subscribers to smarthost messages through their server, how are they letting the subscribers know in some kind of active way? Frank -----Original Message----- From: Suresh Ramasubramanian [mailto:ops.lists at gmail.com] Sent: Saturday, September 13, 2008 8:39 PM To: Frank Bulk Cc: Matthew Moyle-Croft; nanog at nanog.org Subject: Re: ingress SMTP On Sat, Sep 13, 2008 at 11:38 PM, Frank Bulk wrote: > How do you alert mail server operators who are smarthosting their e-mail > through you that their outbound messages contain spam? > > Frank If those are actual mailservers smarthosting and getting MX from you then you doubtless have quite a lot of reporting already set up. Have you seen what Messagelabs, MXLogic etc do? There's also feedback loops, ARF formatted, where users on those mailservers can report inbound spam to the filtering vendor. .. or was that a rhetorical question and am I missing something here? -- Suresh Ramasubramanian (ops.lists at gmail.com) From hank at efes.iucc.ac.il Sun Sep 14 01:42:18 2008 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sun, 14 Sep 2008 09:42:18 +0300 Subject: Internet Traffic Begins to Bypass the U.S. Message-ID: <5.1.0.14.2.20080914084528.00adaeb8@efes.iucc.ac.il> http://www.nytimes.com/2008/08/30/business/30pipes.html?partner=rssuserland&emc=rss&pagewanted=all -Hank From mmc at internode.com.au Sun Sep 14 04:01:51 2008 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Sun, 14 Sep 2008 18:31:51 +0930 Subject: Internet Traffic Begins to Bypass the U.S. In-Reply-To: <5.1.0.14.2.20080914084528.00adaeb8@efes.iucc.ac.il> References: <5.1.0.14.2.20080914084528.00adaeb8@efes.iucc.ac.il> Message-ID: <48CCD2FF.9050201@internode.com.au> I think it began a while ago, but I suspect it'll increase. There's now two trans-Russian terrestrial systems, and more investment in Asia - Europe cables. Initially the capacity will be used for redundancy and to shorten latencies (ie. just to go around the other way and because it's quicker than going US->Atlantic->Europe from Asia). I don't think any of this will be because of sinister reasons, just for good engineering reasons and probably just to guarantee, without a doubt, that your circuit does NOT go through One Wilshire! MMC Hank Nussbacher wrote: > http://www.nytimes.com/2008/08/30/business/30pipes.html?partner=rssuserland&emc=rss&pagewanted=all > > > -Hank > > -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc at internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 From hank at efes.iucc.ac.il Sun Sep 14 04:20:47 2008 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sun, 14 Sep 2008 12:20:47 +0300 Subject: community real-time BGP hijack notification service In-Reply-To: <6C848BB6-7C98-4BF4-93B9-01CBA32A0FC6@nosignal.org> References: Message-ID: <5.1.0.14.2.20080914112612.0590fa80@efes.iucc.ac.il> At 03:07 PM 12-09-08 +0100, Andy Davidson wrote: >On 12 Sep 2008, at 13:49, Nathan Ward wrote: > >>On 12/09/2008, at 10:42 PM, Gadi Evron wrote: >>>Hi, WatchMy.Net is a new community service to alert you when your >>>prefix >>>has been hijacked, in real-time. >>I just had a quick play with this, as I've been considering hacking >>together something similar. > >Everyone with any interest in this topic should look at the MyASN >service from the RIPE NCC (which I use and think is brilliant). > >http://www.ris.ripe.net/myasn.html > >" >The MyASN service notifies network operators when a prefix is >announced with an incorrect AS path. An AS path is seen as incorrect >when it does not match with a regular expression. As not everyone is >familiar with regular expressions, MyASN provides several easy ways to >define typical checks, like "the origin of this prefix must be AS x" >or "the origin of this prefix must be AS x and transit may be provided >through y or z". However, as any AS path regular expression can be >set, the MyASN service is suitable for regular expressions gurus as >well. >" > >To address Nathan's point, I recommend the RIPE service because for >such a service to be ubiquitously useful, it needs to have many eyes >(a view of routing tables at lots of points on the internet) which is >where the very well peered situation of RIS comes into effect. At the >last RIPE meeting I think i saw RIS had over 600 peers, which it >collects at internet exchange points all over the world. I have used IAR, PHAS and MyASN and I can say I would not recommend myASN. It is a cumbersome system and very non-intuitive. It is based on an ASN-centric model, whereby each ASN is in its own realm. So if you manage *one* ASN, perhaps this system might work for you. But if you have about 10 ASNs you want to manage, in one central spot, you are out of luck here. Also, you would expect the system to "auto-learn" what prefixes exist under your ASN and then you would have perhaps check boxes to disable or enable monitoring for specific prefixes. With myASN you have to manually type in each and every prefix you have. The same holds true for the newer http://ripe.net/is/alarms/. They also differentiate between origin and transit ASN. Their summary view doesn't show which prefixes are being monitored. No help or FAQ available yet on the beta alarms system. PHAS doesn't look at ASNs just prefixes. You have to register each and every prefix via their site at: http://phas.netsec.colostate.edu/subscribe.html Problem is to remove prefixes you have to totally unsubscribe via: http://phas.netsec.colostate.edu/unsubscribe.html You can't manage/unsubscribe individual prefixes. And if you registered years ago before they instituted the ID and key factor for unsubscribing (as I did), you have no way to figure out how to unsubscribe from their email notices. Their notices provide many false alarms based on my observation over the past few years. The best system so far would be IAR: http://iar.cs.unm.edu/ The email notices are pretty much on time and accurate. Problem is they have changed the system and I believe some forum page/link has gone lost that allows one to manage existing subscriptions as per: http://iar.cs.unm.edu/alerts.php#email Now for the new boy in town - Watchmy.net. When you register it doesn't say you need at least an 8 char pswd. I did 7. So it wipes out all form data entered (name, phone number, etc.) and makes you start again from scratch. The Web interface seems the most intuitive of all 4 but since I am just starting to use it - I will only discover the warts over the next week. In general, academic systems like UNM and Colostate are the baby of some post-doc and then disappear after they leave or move on. By nature, CS and EE departments don't like ot care to run production systems. That is why I had high hopes for the RIPE system, which unfortunately, IMHO, is the worst. It is funded via membership dues and one would expect that the authors would poll the RIPE community for what functionality they would need. That has not been done. Even when they get feedback (as far back as 2003) they just ignore it and continue doing the development based on what they *believe* is what we need, rather than *asking* what we need. That is why I am hoping that Watchmy.Net will not only listen to the community needs, but also have a committment for long term maintenance. Regards, Hank >best wishes >Andy From hank at efes.iucc.ac.il Sun Sep 14 10:00:19 2008 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sun, 14 Sep 2008 18:00:19 +0300 (IDT) Subject: community real-time BGP hijack notification service In-Reply-To: References: <5.1.0.14.2.20080914112612.0590fa80@efes.iucc.ac.il> Message-ID: >> The best system so far would be IAR: http://iar.cs.unm.edu/ >> The email notices are pretty much on time and accurate. Problem is they >> have changed the system and I believe some forum page/link has gone lost >> that allows one to manage existing subscriptions as per: >> http://iar.cs.unm.edu/alerts.php#email Correction: the page exists although difficult to find. As per Josh: "Once you login on the IAR forums, toward the top left of the page is a "user control panel" button. Click that and go to the "profile" tab. At the bottom of that page is a field: "user_ases". -Hank From pekkas at netcore.fi Sun Sep 14 10:55:46 2008 From: pekkas at netcore.fi (Pekka Savola) Date: Sun, 14 Sep 2008 18:55:46 +0300 (EEST) Subject: community real-time BGP hijack notification service In-Reply-To: <5.1.0.14.2.20080914112612.0590fa80@efes.iucc.ac.il> References: <5.1.0.14.2.20080914112612.0590fa80@efes.iucc.ac.il> Message-ID: On Sun, 14 Sep 2008, Hank Nussbacher wrote: > I have used IAR, PHAS and MyASN and I can say I would not recommend myASN. > It is a cumbersome system and very non-intuitive. It is based on an > ASN-centric model, whereby each ASN is in its own realm. So if you manage > *one* ASN, perhaps this system might work for you. But if you have about 10 > ASNs you want to manage, in one central spot, you are out of luck here. > Also, you would expect the system to "auto-learn" what prefixes exist under > your ASN and then you would have perhaps check boxes to disable or enable > monitoring for specific prefixes. With myASN you have to manually type in > each and every prefix you have. The same holds true for the newer > http://ripe.net/is/alarms/. They also differentiate between origin and > transit ASN. Their summary view doesn't show which prefixes are being > monitored. No help or FAQ available yet on the beta alarms system. I think I'll need to chime in here, being a user of myASN. I have not tested other systems. To me it seems to work OK. Manual typing etc. is minimized because you can export and import XML; this is the way I entered our prefix information in the database (though if the prefixes change often, maybe updates would be a chore). The database itself AFAIR does not have any restriction on what it's monitoring when you use the advanced interface -- you can insert any AS-path regexes you want, and that way we're managing prefixes from some ~5-10 ASNs. AFAICS, the ASN in login form is only used for identification purposes and in some shortcuts in the basic interface. I agree that to kickstart monitoring, an auto-learning feature could be used. And that documentation is somewhat sparse :-). I've gotten a couple of alarms which may or may have been bogus. One academic site was purpotedly advertising one of our prefixes duing one day for a couple of 1-2 hour periods. Upon asking they said they had not done anything special, and said that their upstreams wouldn't accept that kind of prefix from them anyway. Not sure if that was true, but I didn't purse this further. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From patrick at ianai.net Sun Sep 14 11:52:29 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 14 Sep 2008 12:52:29 -0400 Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: <20080912114823.F44215@sprockets.gibbard.org> References: <20080908112049.256D9BBE@resin13.mta.everyone.net> <200809120142.08768.lowen@pari.edu> <872B38BF-232D-4798-A764-5B1486A77791@ianai.net> <20080912114823.F44215@sprockets.gibbard.org> Message-ID: <4F26A645-ABF7-4EC2-A5E1-494B7F0911D4@ianai.net> On Sep 12, 2008, at 3:02 PM, Steve Gibbard wrote: > On Fri, 12 Sep 2008, Patrick W. Gilmore wrote: > >> Going back a bit in case you forgot, we were discussing the fact >> you have NO RIGHT to connect to my network, it is a privilege, not >> a right. You responded with: "If I have either a peering >> agreement ... then that contract supports my 'rights' under that >> contract persuant to my responsibilities being fulfilled." Then >> you posted this contract as an example of those "rights". From the >> contract you claim to be "a great model": > It's probably correct that any individual player in this industry > not under other regulatory restrictions can refuse to do business > with somebody they don't like, sometimes. Probably? > For the industry as a whole to make a group decision to not do > business with somebody who may be a competitor seems more legally > risky. Engaging in that sort of thing without getting some good > legal advice first would certainly make me nervous. "The industry as a whole"? And who in their right minds considers Atrivo or InterCage a competitor? Are you upset at InterCage for lost child pr0n customers? > Since this appears to be somebody who is contracting with lots of US > providers, their identity is presumably known. This discussion has > now been going on for long enough that it's presumably passed the > emergency, "act now; think later," phase. Should what they're doing > be a law enforcement issue, rather than a "they've got cooties" issue? You have been around more than long enough to know better than that Steve. And you should be more consistent. Is this a US problem or an Internet problem? -- TTFN, patrick From mmc at internode.com.au Sun Sep 14 18:26:01 2008 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Mon, 15 Sep 2008 08:56:01 +0930 Subject: Internet Traffic Begins to Bypass the U.S. In-Reply-To: <48CCD2FF.9050201@internode.com.au> References: <5.1.0.14.2.20080914084528.00adaeb8@efes.iucc.ac.il> <48CCD2FF.9050201@internode.com.au> Message-ID: <48CD9D89.1000501@internode.com.au> Matthew Moyle-Croft wrote: > > I don't think any of this will be because of sinister reasons, just > for good engineering reasons and probably just to guarantee, without a > doubt, that your circuit does NOT go through One Wilshire! Just to ensure no confusion - this was just about redundancy and diversity to ensure that not all your circuits go through OW, which is a common US West Coast issue. MMC From jal at jal.org Sun Sep 14 18:32:29 2008 From: jal at jal.org (Jamie A Lawrence) Date: Sun, 14 Sep 2008 19:32:29 -0400 Subject: Internet Traffic Begins to Bypass the U.S. In-Reply-To: <48CD9D89.1000501@internode.com.au> References: <5.1.0.14.2.20080914084528.00adaeb8@efes.iucc.ac.il> <48CCD2FF.9050201@internode.com.au> <48CD9D89.1000501@internode.com.au> Message-ID: >> I don't think any of this will be because of sinister reasons, just >> for good engineering reasons and probably just to guarantee, >> without a doubt, that your circuit does NOT go through One Wilshire! What exactly would be sinister about moving traffic through routes that didn't intersect the U.S. border? -j From jfmezei at vaxination.ca Sun Sep 14 18:41:17 2008 From: jfmezei at vaxination.ca (=?ISO-8859-1?Q?Jean-Fran=E7ois_Mezei?=) Date: Sun, 14 Sep 2008 19:41:17 -0400 Subject: Internet Traffic Begins to Bypass the U.S. In-Reply-To: <5.1.0.14.2.20080914084528.00adaeb8@efes.iucc.ac.il> References: <5.1.0.14.2.20080914084528.00adaeb8@efes.iucc.ac.il> Message-ID: <48CDA11D.2070407@vaxination.ca> Hank Nussbacher wrote: > http://www.nytimes.com/2008/08/30/business/30pipes.html?partner=rssuserland&emc=rss&pagewanted=all Pardon my ignorance here, but isn't this more of a case of traffic growing outside of the USA which means that traffic within the USA represents a smaller share of the total internet traffic ? Did western europe ever really have a primary route via the USA to reach asia ? (I realise that during the cable cuts in middle east last year, traffic might have been rerouted via USA but this would be a temporary situation). There may be political issues since the USA decided that there was to be no privacy with regards to traffic flowing to/from non-USA countries (so the 3 letter acronym orgs could spy/record that traffic without warrant). However, I am not sure if other transit providers would have built cables designed to avoid transit via the USA since then. It takes time to build a cable. From mmc at internode.com.au Sun Sep 14 18:47:18 2008 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Mon, 15 Sep 2008 09:17:18 +0930 Subject: Internet Traffic Begins to Bypass the U.S. In-Reply-To: References: <5.1.0.14.2.20080914084528.00adaeb8@efes.iucc.ac.il> <48CCD2FF.9050201@internode.com.au> <48CD9D89.1000501@internode.com.au> Message-ID: <48CDA286.4000201@internode.com.au> Jamie A Lawrence wrote: > > > What exactly would be sinister about moving traffic through routes > that didn't intersect the U.S. border? Nothing if the reason isn't to avoid the US to prevent interception. ie. my point was the people are doing this for engineering reasons not political ones as was implied by that article. We have connectivity to Japan to reduce latency to Asia from Australia (ie. remove the trombone via the US) - this is purely an engineering/commercial decision to improve latency. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks From mmc at internode.com.au Sun Sep 14 18:52:56 2008 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Mon, 15 Sep 2008 09:22:56 +0930 Subject: Internet Traffic Begins to Bypass the U.S. In-Reply-To: <48CDA11D.2070407@vaxination.ca> References: <5.1.0.14.2.20080914084528.00adaeb8@efes.iucc.ac.il> <48CDA11D.2070407@vaxination.ca> Message-ID: <48CDA3D8.8030006@internode.com.au> > Pardon my ignorance here, but isn't this more of a case of traffic > growing outside of the USA which means that traffic within the USA > represents a smaller share of the total internet traffic ? > I suspect so - especially with CDN/Content providers pushing traffic out to the edge it means that we (the rest of the world) don't pay so much to haul it back from Northern America! (Thanks to those who are doing it - you know who you are and we love you for it!). Japan has 80% of it's internet traffic as domestic, as do a lot of Asian countries. As China, Korea and others grow their domestic volumes the %age coming from the USA is a lot less. > > Did western europe ever really have a primary route via the USA to reach > asia ? (I realise that during the cable cuts in middle east last year, > traffic might have been rerouted via USA but this would be a temporary > situation). > Most Asian providers (at least Northern Asia) use USA, Atlantic path to get to Europe. The capacity going Westt isn't that high in comparision, so the extra latency hit is well offset by the much reduced cost. My point in my first post is that this is changing rapidly as people (eg Reliance/Flag) are building more capacity West to Europe plus the Trans-Russian terrestrial (eg. TEA) are going for fast (and expensive from my understanding). For instance, out of Australia we have a single, old cable going West out of Perth to Singapore (SEA-ME-WE3) which allows only low speed circuits, but we've got almost 4 (as of next year) cables going North and East out of Sydney. So most Europe traffic to/from Australia is via the USA. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc at internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 From sking at kingrst.com Sun Sep 14 19:27:08 2008 From: sking at kingrst.com (Steven King) Date: Sun, 14 Sep 2008 20:27:08 -0400 Subject: ARP Table Timeout and Mac-Address-Table Timeout Message-ID: <48CDABDC.80302@kingrst.com> I am a network engineer for a large web hosting company. We are having an issue with our distribution routers flooding traffic in one of our VLANs. We have a customer with a routed mode ASA 5550. They have their own private VLAN that is a /23 This VLAN is 145. The outside interface of the firewall is in VLAN 132. We are routing all traffic for VLAN 145 to the IP of the outside interface of the firewall in VLAN 132. VLAN 132 is Layer3 routable and VLAN 145 is only Layer2 switchable. We have two distribution switches which are redundant with HSRP. Dist1 is the active forwarder in this case. Traffic coming into these two routers are load balanced between Dist1 and Dist2 with EIGRP routes with equal cost. We have found that traffic coming into Dist2 (the standby) is flooding traffic destined for the firewall outside interface. But Dist1 is not. We have tracked down the cause of this to the MAC-Address-Table timing out before the ARP table times out. We leave these values at the Cisco default. ARP = 4hr MAC = 5 minutes. Since Dist2 is not receiving any traffic from the firewall going out to the internet, it is not updating the MAC-Address-Table after it expires. Instead, it waits 4 hours for the ARP cache to expire for that IP, and then updates everything. But Dist2 ends up flooding traffic for that 4 hours causing latency. We have done some research on this problem and have found so far the best solution to be to make the ARP timeout less than the MAC-Address-Table aging-timer.We have set the ARP = 1hr and MAC = 2hrs in this case to correct the problem. So when the ARP entry times out before the MAC entry, the forced update of the ARP entry before the MAC timeout causes the MAC entry age to reset. Indeed this does correct the problem. Is this the best solution to the problem, or is there another preferred solution? Has anyone ran into this in their own Enterprise Networks? Please let me know if I didn't explain anything well enough. -- Steve King Network Engineer - Liquid Web, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA Network+ Certified Professional CompTIA A+ Certified Professional From rubensk at gmail.com Sun Sep 14 19:41:26 2008 From: rubensk at gmail.com (Rubens Kuhl Jr.) Date: Sun, 14 Sep 2008 21:41:26 -0300 Subject: Internet Traffic Begins to Bypass the U.S. In-Reply-To: <48CDA3D8.8030006@internode.com.au> References: <5.1.0.14.2.20080914084528.00adaeb8@efes.iucc.ac.il> <48CDA11D.2070407@vaxination.ca> <48CDA3D8.8030006@internode.com.au> Message-ID: <6bb5f5b10809141741w150bf899v1c471d48e135c048@mail.gmail.com> > For instance, out of Australia we have a single, old cable going West out of > Perth to Singapore (SEA-ME-WE3) which allows only low speed circuits, but > we've got almost 4 (as of next year) cables going North and East out of > Sydney. So most Europe traffic to/from Australia is via the USA. Which is not a political problem, as Australia, New Zealand, Canada, Great Britain and the USA share Echelon and other intelligence systems... Russia, France and Germain might have other feelings about traffic going through the USA or UK when it is not directed to one of above. Rubens From leothelion.murtaza at gmail.com Sun Sep 14 19:41:28 2008 From: leothelion.murtaza at gmail.com (Murtaza) Date: Mon, 15 Sep 2008 06:11:28 +0530 Subject: Internet Traffic Begins to Bypass the U.S. In-Reply-To: <48CDA3D8.8030006@internode.com.au> References: <5.1.0.14.2.20080914084528.00adaeb8@efes.iucc.ac.il> <48CDA11D.2070407@vaxination.ca> <48CDA3D8.8030006@internode.com.au> Message-ID: <949b74980809141741h4261de3dx6ac2bb9f4c9f5420@mail.gmail.com> Nothing if the reason isn't to avoid the US to prevent interception. ie. my point was the people are doing this for engineering reasons not political ones as was implied by that article. I don't see it sinister even if someone wants to avoid US due to interception. But, yes I agree people are doing for engineering reasons. But, it still is impossible in many asses, as ISPs in many countries are still not cooperating with each other. On Mon, Sep 15, 2008 at 5:22 AM, Matthew Moyle-Croft wrote: > > Pardon my ignorance here, but isn't this more of a case of traffic >> growing outside of the USA which means that traffic within the USA >> represents a smaller share of the total internet traffic ? >> >> > I suspect so - especially with CDN/Content providers pushing traffic out to > the edge it means that we (the rest of the world) don't pay so much to haul > it back from Northern America! (Thanks to those who are doing it - you > know who you are and we love you for it!). > > Japan has 80% of it's internet traffic as domestic, as do a lot of Asian > countries. As China, Korea and others grow their domestic volumes the %age > coming from the USA is a lot less. > >> >> Did western europe ever really have a primary route via the USA to reach >> asia ? (I realise that during the cable cuts in middle east last year, >> traffic might have been rerouted via USA but this would be a temporary >> situation). >> >> > Most Asian providers (at least Northern Asia) use USA, Atlantic path to get > to Europe. The capacity going Westt isn't that high in comparision, so the > extra latency hit is well offset by the much reduced cost. My point in my > first post is that this is changing rapidly as people (eg Reliance/Flag) are > building more capacity West to Europe plus the Trans-Russian terrestrial > (eg. TEA) are going for fast (and expensive from my understanding). > > For instance, out of Australia we have a single, old cable going West out > of Perth to Singapore (SEA-ME-WE3) which allows only low speed circuits, but > we've got almost 4 (as of next year) cables going North and East out of > Sydney. So most Europe traffic to/from Australia is via the USA. > > MMC > > -- > Matthew Moyle-Croft - Internode/Agile - Networks > Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia > Email: mmc at internode.com.au Web: http://www.on.net > Direct: +61-8-8228-2909 Mobile: +61-419-900-366 > Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 > > > -- Ghulam Murtaza From leothelion.murtaza at gmail.com Sun Sep 14 19:42:32 2008 From: leothelion.murtaza at gmail.com (Murtaza) Date: Mon, 15 Sep 2008 06:12:32 +0530 Subject: Internet Traffic Begins to Bypass the U.S. In-Reply-To: <949b74980809141741h4261de3dx6ac2bb9f4c9f5420@mail.gmail.com> References: <5.1.0.14.2.20080914084528.00adaeb8@efes.iucc.ac.il> <48CDA11D.2070407@vaxination.ca> <48CDA3D8.8030006@internode.com.au> <949b74980809141741h4261de3dx6ac2bb9f4c9f5420@mail.gmail.com> Message-ID: <949b74980809141742n4916d4cbkc0da8e6654d3a05b@mail.gmail.com> But, it still is impossible in many asses, as ISPs in many countries are still not cooperating with each other. But, it still is impossible in many cases, On Mon, Sep 15, 2008 at 6:11 AM, Murtaza wrote: > Nothing if the reason isn't to avoid the US to prevent interception. ie. > my point was the people are doing this for engineering reasons not > political ones as was implied by that article. > > I don't see it sinister even if someone wants to avoid US due to > interception. But, yes I agree people are doing for engineering reasons. > But, it still is impossible in many asses, as ISPs in many countries are > still not cooperating with each other. > > > On Mon, Sep 15, 2008 at 5:22 AM, Matthew Moyle-Croft > wrote: > >> >> Pardon my ignorance here, but isn't this more of a case of traffic >>> growing outside of the USA which means that traffic within the USA >>> represents a smaller share of the total internet traffic ? >>> >>> >> I suspect so - especially with CDN/Content providers pushing traffic out >> to the edge it means that we (the rest of the world) don't pay so much to >> haul it back from Northern America! (Thanks to those who are doing it - >> you know who you are and we love you for it!). >> >> Japan has 80% of it's internet traffic as domestic, as do a lot of Asian >> countries. As China, Korea and others grow their domestic volumes the %age >> coming from the USA is a lot less. >> >>> >>> Did western europe ever really have a primary route via the USA to reach >>> asia ? (I realise that during the cable cuts in middle east last year, >>> traffic might have been rerouted via USA but this would be a temporary >>> situation). >>> >>> >> Most Asian providers (at least Northern Asia) use USA, Atlantic path to >> get to Europe. The capacity going Westt isn't that high in comparision, so >> the extra latency hit is well offset by the much reduced cost. My point in >> my first post is that this is changing rapidly as people (eg Reliance/Flag) >> are building more capacity West to Europe plus the Trans-Russian terrestrial >> (eg. TEA) are going for fast (and expensive from my understanding). >> >> For instance, out of Australia we have a single, old cable going West out >> of Perth to Singapore (SEA-ME-WE3) which allows only low speed circuits, but >> we've got almost 4 (as of next year) cables going North and East out of >> Sydney. So most Europe traffic to/from Australia is via the USA. >> >> MMC >> >> -- >> Matthew Moyle-Croft - Internode/Agile - Networks >> Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia >> Email: mmc at internode.com.au Web: http://www.on.net >> Direct: +61-8-8228-2909 Mobile: +61-419-900-366 >> Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 >> >> >> > > > -- > Ghulam Murtaza > > -- Ghulam Murtaza Lahore University of Management Sciences From jfmezei at vaxination.ca Sun Sep 14 20:16:26 2008 From: jfmezei at vaxination.ca (=?ISO-8859-1?Q?Jean-Fran=E7ois_Mezei?=) Date: Sun, 14 Sep 2008 21:16:26 -0400 Subject: Internet Traffic Begins to Bypass the U.S. In-Reply-To: <48CDA3D8.8030006@internode.com.au> References: <5.1.0.14.2.20080914084528.00adaeb8@efes.iucc.ac.il> <48CDA11D.2070407@vaxination.ca> <48CDA3D8.8030006@internode.com.au> Message-ID: <48CDB76A.3030009@vaxination.ca> Matthew Moyle-Croft wrote: > Most Asian providers (at least Northern Asia) use USA, Atlantic path to > get to Europe. The capacity going Westt isn't that high in comparision, > so the extra latency hit is well offset by the much reduced cost. I take it voice would have priority for use of the existing europe-asian links ? When there were a number of cable cuts in middle east last year, I remember BBC mentioning that internet access to asia was much slowed due (this was significant to those companies who had outsourced a lot of stuff from europe to India). I guess this would have been more of media hype than reality ? > For instance, out of Australia we have a single, old cable going West > out of Perth to Singapore (SEA-ME-WE3) which allows only low speed > circuits, Was there any thought about building cables to singapore from darwin now that it has had fibre links to the rest of australia for over a decade ? From mmc at internode.com.au Sun Sep 14 20:34:41 2008 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Mon, 15 Sep 2008 11:04:41 +0930 Subject: Internet Traffic Begins to Bypass the U.S. In-Reply-To: <48CDB76A.3030009@vaxination.ca> References: <5.1.0.14.2.20080914084528.00adaeb8@efes.iucc.ac.il> <48CDA11D.2070407@vaxination.ca> <48CDA3D8.8030006@internode.com.au> <48CDB76A.3030009@vaxination.ca> Message-ID: <14BD774C-B776-4BEE-BF8D-AB4975F0AB84@internode.com.au> On 15/09/2008, at 10:46 AM, Jean-Fran?ois Mezei wrote: > Matthew Moyle-Croft wrote: > >> Most Asian providers (at least Northern Asia) use USA, Atlantic >> path to >> get to Europe. The capacity going Westt isn't that high in >> comparision, >> so the extra latency hit is well offset by the much reduced cost. > > I take it voice would have priority for use of the existing europe- > asian > links ? Probably - voice is pretty small in the scheme of things (my estimate is less than 1% of used capacity out of Australia (used not lit)). But, from Australia to Europe the difference in latency East vs West may not make a LOT of difference to voice where 150ms-200ms one way isn't too bad. > > > When there were a number of cable cuts in middle east last year, I > remember BBC mentioning that internet access to asia was much slowed > due > (this was significant to those companies who had outsourced a lot of > stuff from europe to India). I guess this would have been more of > media > hype than reality ? I suspect it did slow it down - I was talking more Northern Asia (China, Japan, Korea) than India. Companies who relied on purchasing, corporate links between India and Europe (for example) would probably be happy to pay the premium for low latency path direct, whereas IP transit providers want cheap, bulk capacity that the Northern Pacific routers offer. > > >> For instance, out of Australia we have a single, old cable going West >> out of Perth to Singapore (SEA-ME-WE3) which allows only low speed >> circuits, > > Was there any thought about building cables to singapore from darwin > now > that it has had fibre links to the rest of australia for over a > decade ? Ha! Darwin has the incumbent only. It's cheaper to go around the world than from Australia to Darwin. Perth will be the place again as there is a reasonable amount of trans- Australian capacity across the Nullabour. Although a Darwin break out from such a cable would be welcome, but the small population in the Northern Territory maybe doesn't make it viable unless a big mining /oil drilling/gas firm wants a lot of capacity. Hopefully the extension of the Singapore->Indonesia cable Matrix have/ are building to Perth will happen in 2010/11. Although, personally, I'd love to see a Perth-Chennai cable given what's going on in India. MMC -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks From jabley at ca.afilias.info Sun Sep 14 20:36:12 2008 From: jabley at ca.afilias.info (Joe Abley) Date: Sun, 14 Sep 2008 21:36:12 -0400 Subject: Internet Traffic Begins to Bypass the U.S. In-Reply-To: <48CDA11D.2070407@vaxination.ca> References: <5.1.0.14.2.20080914084528.00adaeb8@efes.iucc.ac.il> <48CDA11D.2070407@vaxination.ca> Message-ID: On 14 Sep 2008, at 19:41, Jean-Fran?ois Mezei wrote: > Did western europe ever really have a primary route via the USA to > reach > asia ? Yes, I think so. If I remember correctly, before FLAG started laying cables, there was no terrestrial route to Asia from Europe that didn't involve North America. Joe From frnkblk at iname.com Sun Sep 14 22:19:53 2008 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 14 Sep 2008 22:19:53 -0500 Subject: ARP Table Timeout and Mac-Address-Table Timeout In-Reply-To: <48CDABDC.80302@kingrst.com> References: <48CDABDC.80302@kingrst.com> Message-ID: Steven: This was recently discussed on cisco-nsp: http://marc.info/?l=cisco-nsp&m=121316151010190&w=2 Frank -----Original Message----- From: Steven King [mailto:sking at kingrst.com] Sent: Sunday, September 14, 2008 7:27 PM To: nanog at nanog.org Subject: ARP Table Timeout and Mac-Address-Table Timeout I am a network engineer for a large web hosting company. We are having an issue with our distribution routers flooding traffic in one of our VLANs. We have a customer with a routed mode ASA 5550. They have their own private VLAN that is a /23 This VLAN is 145. The outside interface of the firewall is in VLAN 132. We are routing all traffic for VLAN 145 to the IP of the outside interface of the firewall in VLAN 132. VLAN 132 is Layer3 routable and VLAN 145 is only Layer2 switchable. We have two distribution switches which are redundant with HSRP. Dist1 is the active forwarder in this case. Traffic coming into these two routers are load balanced between Dist1 and Dist2 with EIGRP routes with equal cost. We have found that traffic coming into Dist2 (the standby) is flooding traffic destined for the firewall outside interface. But Dist1 is not. We have tracked down the cause of this to the MAC-Address-Table timing out before the ARP table times out. We leave these values at the Cisco default. ARP = 4hr MAC = 5 minutes. Since Dist2 is not receiving any traffic from the firewall going out to the internet, it is not updating the MAC-Address-Table after it expires. Instead, it waits 4 hours for the ARP cache to expire for that IP, and then updates everything. But Dist2 ends up flooding traffic for that 4 hours causing latency. We have done some research on this problem and have found so far the best solution to be to make the ARP timeout less than the MAC-Address-Table aging-timer.We have set the ARP = 1hr and MAC = 2hrs in this case to correct the problem. So when the ARP entry times out before the MAC entry, the forced update of the ARP entry before the MAC timeout causes the MAC entry age to reset. Indeed this does correct the problem. Is this the best solution to the problem, or is there another preferred solution? Has anyone ran into this in their own Enterprise Networks? Please let me know if I didn't explain anything well enough. -- Steve King Network Engineer - Liquid Web, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA Network+ Certified Professional CompTIA A+ Certified Professional From mmc at internode.com.au Sun Sep 14 22:38:43 2008 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Mon, 15 Sep 2008 13:08:43 +0930 Subject: Internet Traffic Begins to Bypass the U.S. In-Reply-To: References: <5.1.0.14.2.20080914084528.00adaeb8@efes.iucc.ac.il> <48CDA11D.2070407@vaxination.ca> Message-ID: <9F1A98CD-2A7C-4E47-B271-049D80B4FBCC@internode.com.au> Other cable systems predated FLAG (at least for voice). SEA-ME-WE predates FLAG by almost a decade. I'm sure some digging would reveal a bit more on that path either submarine or terrestrial. MMC On 15/09/2008, at 11:06 AM, Joe Abley wrote: > > On 14 Sep 2008, at 19:41, Jean-Fran?ois Mezei wrote: > >> Did western europe ever really have a primary route via the USA to >> reach >> asia ? > > Yes, I think so. If I remember correctly, before FLAG started laying > cables, there was no terrestrial route to Asia from Europe that > didn't involve North America. > > > Joe > > > -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc at internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 From jim at reptiles.org Mon Sep 15 01:13:45 2008 From: jim at reptiles.org (Jim Mercer) Date: Mon, 15 Sep 2008 02:13:45 -0400 Subject: Internet Traffic Begins to Bypass the U.S. In-Reply-To: <949b74980809141741h4261de3dx6ac2bb9f4c9f5420@mail.gmail.com> References: <5.1.0.14.2.20080914084528.00adaeb8@efes.iucc.ac.il> <48CDA11D.2070407@vaxination.ca> <48CDA3D8.8030006@internode.com.au> <949b74980809141741h4261de3dx6ac2bb9f4c9f5420@mail.gmail.com> Message-ID: <20080915061345.GA409@reptiles.org> On Mon, Sep 15, 2008 at 06:11:28AM +0530, Murtaza wrote: > Nothing if the reason isn't to avoid the US to prevent interception. ie. > my point was the people are doing this for engineering reasons not > political ones as was implied by that article. > > I don't see it sinister even if someone wants to avoid US due to > interception. But, yes I agree people are doing for engineering reasons. > But, it still is impossible in many asses, as ISPs in many countries are > still not cooperating with each other. speaking from the middle east, i have been advising my clients against co-location/hosting in the US due to potential political issues. the current US policy of "detain first, question later" has the potential for serious customer relations issues, should one of the TLAs become interested in your data. oddly enough, the ISP's in the region have not caught on to the potential winfall of providing cost effective hosting locally, so therefore, the bulk of the hosting for companies in the region is primarily done in the US, then in EU, then, maybe locally. if you drive down Sheikh Zayed Road in Dubai, and check where the hosting is for 90% of the URL's on the billboards (even those with .ae domains), you will find that they follow the above pattern. a primary example is that of du.ae, one of the only two incumbent/dual-opoly providers for the UAE, hosts its own website and customer portal in Canada, even though it has a perfectly fine data center (if not more than one) in Dubai. UAE/Dubai is a major landing point for many asian/indian ocean fibers, but there is no equivilent of One Wilshire/60 Hudson/etc. so, as the data finds more and better direct routes to the end user, reducing the need to route through the US, there is still a penchant for hosting the primary data there. -- Jim Mercer jim at reptiles.org +971 55 410-5633 "I'm Prime Minister of Canada, I live here and I'm going to take a leak." - Lester Pearson in 1967, during a meeting between himself and President Lyndon Johnson, whose Secret Service detail had taken over Pearson's cottage retreat. At one point, a Johnson guard asked Pearson, "Who are you and where are you going?" From fergdawg at netzero.net Mon Sep 15 01:19:02 2008 From: fergdawg at netzero.net (Paul Ferguson) Date: Mon, 15 Sep 2008 06:19:02 GMT Subject: Internet Traffic Begins to Bypass the U.S. Message-ID: <20080914.231902.7577.0@webmail03.vgs.untd.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Jim Mercer wrote: >UAE/Dubai is a major landing point for many asian/indian ocean fibers, but >there is no equivilent of One Wilshire/60 Hudson/etc. > >so, as the data finds more and better direct routes to the end user, >reducing the need to route through the US, there is still a penchant for >hosting the primary data there. A direct route to the criminals, too: http://www.arabianbusiness.com/530800-uae-banks-step-up-security-after-card - -theft - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFIzf5Nq1pz9mNUZTMRAjcnAKC6o9PncwyXAQ3P8kIZC1Ca0n60nACeNLzV P/rKYAjJGGKbp1GDaMvgx2Y= =lbak -----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 Mon Sep 15 02:32:51 2008 From: fergdawg at netzero.net (Paul Ferguson) Date: Mon, 15 Sep 2008 07:32:51 GMT Subject: Atrivo/Intercage: Now Only 1 Upstream Message-ID: <20080915.003251.7577.3@webmail03.vgs.untd.com> Looks like WVFiber removed them as a customer: http://www.cidr-report.org/cgi-bin/as-report?as=as27595 Now only AS32335 [PACIFICINTERNETEXCHANGE-NET] remains. - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ From sking at kingrst.com Mon Sep 15 03:52:12 2008 From: sking at kingrst.com (Steven King) Date: Mon, 15 Sep 2008 04:52:12 -0400 Subject: ARP Table Timeout and Mac-Address-Table Timeout In-Reply-To: References: <48CDABDC.80302@kingrst.com> Message-ID: <48CE223C.9090901@kingrst.com> I saw that one before. Thats what we based our current fix on. Frank Bulk wrote: > Steven: > > This was recently discussed on cisco-nsp: > http://marc.info/?l=cisco-nsp&m=121316151010190&w=2 > > Frank > > -----Original Message----- > From: Steven King [mailto:sking at kingrst.com] > Sent: Sunday, September 14, 2008 7:27 PM > To: nanog at nanog.org > Subject: ARP Table Timeout and Mac-Address-Table Timeout > > I am a network engineer for a large web hosting company. We are having > an issue with our distribution routers flooding traffic in one of our VLANs. > > We have a customer with a routed mode ASA 5550. They have their own > private VLAN that is a /23 This VLAN is 145. The outside interface of > the firewall is in VLAN 132. We are routing all traffic for VLAN 145 to > the IP of the outside interface of the firewall in VLAN 132. > > VLAN 132 is Layer3 routable and VLAN 145 is only Layer2 switchable. > > We have two distribution switches which are redundant with HSRP. Dist1 > is the active forwarder in this case. Traffic coming into these two > routers are load balanced between Dist1 and Dist2 with EIGRP routes with > equal cost. > > We have found that traffic coming into Dist2 (the standby) is flooding > traffic destined for the firewall outside interface. But Dist1 is not. > > We have tracked down the cause of this to the MAC-Address-Table timing > out before the ARP table times out. We leave these values at the Cisco > default. ARP = 4hr MAC = 5 minutes. Since Dist2 is not receiving any > traffic from the firewall going out to the internet, it is not updating > the MAC-Address-Table after it expires. Instead, it waits 4 hours for > the ARP cache to expire for that IP, and then updates everything. But > Dist2 ends up flooding traffic for that 4 hours causing latency. > > We have done some research on this problem and have found so far the > best solution to be to make the ARP timeout less than the > MAC-Address-Table aging-timer.We have set the ARP = 1hr and MAC = 2hrs > in this case to correct the problem. So when the ARP entry times out > before the MAC entry, the forced update of the ARP entry before the MAC > timeout causes the MAC entry age to reset. Indeed this does correct the > problem. > > Is this the best solution to the problem, or is there another preferred > solution? Has anyone ran into this in their own Enterprise Networks? > > Please let me know if I didn't explain anything well enough. > > -- > Steve King > > Network Engineer - Liquid Web, Inc. > Cisco Certified Network Associate > CompTIA Linux+ Certified Professional > CompTIA Network+ Certified Professional > CompTIA A+ Certified Professional > > > > -- Steve King Network Engineer - Liquid Web, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA Network+ Certified Professional CompTIA A+ Certified Professional From simon at darkmere.gen.nz Mon Sep 15 04:06:10 2008 From: simon at darkmere.gen.nz (NANOG Mail List Committee) Date: Mon, 15 Sep 2008 21:06:10 +1200 Subject: NANOG List Monthly Post. Message-ID: General Information =================== About NANOG: http://www.nanog.org/about/ NANOG News: http://www.nanog.org/ NANOG lists and AUP: http://www.nanog.org/mailinglist/ NANOG List FAQ: http://www.nanog.org/mailinglist/listfaqs/ To Subscribe or Unsubscribe from the list: http://mailman.nanog.org/mailman/listinfo/nanog To contact the list's admins: admins at nanog.org Posting Policy ============== The NANOG list has over 10,000 subscribers so it is very easy for a thread to have scores of posts while being off-topic and only of interest to only a small proportion of subscribers. Please consider before each post if your email will be of interest to the majority of members or might alternatively be emailed directly the people of interest or posted to another forum. Please read the FAQ and AUP policy before posting for more details. Especially the following are discouraged: * Is a certain site down? Other Outages not affecting half the Internet. Please use http://downforeveryoneorjustme.com/ or a similar site. Please post to the Outages mailing list: https://puck.nether.net/mailman/listinfo/outages * Spam Please use SPAM-L - http://www.claws-and-paws.com/spam-l * Contacting People * http://puck.nether.net/netops/ * Please try other methods of contacting sites before you post to NANOG. Saying something like "I tried calling 213-555-3333 but no answer" shows you _have_ tried alternative methods first. * Political Issues * Topics such as ICANN policy, Government Policy or Law changes that do not have short term Operational impact should be avoided. * Operation topics with more specific lists * DNS - http://lists.oarci.net/mailman/listinfo/dns-operations * Email - http://www.mailop.org/ * NANOG Mailing list policy Please use the nanog-futures list or contact admins at nanog.org Please also avoid ================= * Sending posts to the list relevant to only one or two people on this list, such as tests or traceroutes in response to another post for comparison to those originally posted. * Jokes, Puns, amusing observations, spelling corrections. Other NANOG related lists ========================= * NANOG-futures - for discussion of the evolution of NANOG, including organizational structure, policies and procedures, and agendas for NANOG meetings. Such topics aren't appropriate for the main NANOG mailing list. http://mailman.nanog.org/mailman/listinfo/nanog-futures * nanog-attendee - For discussion of venue-specific issues relevant to attendees of the current NANOG physical meeting. http://mailman.nanog.org/mailman/listinfo/nanog-attendee * nanog-announce - For announcements of NANOG meetings an other Important NANOG related announcements. Low traffic and all posts are also sent to main list. http://mailman.nanog.org/mailman/listinfo/nanog-announce Other Mailing Lists =================== Information about related lists: http://www.nanog.org/mailinglist/listfaqs/otherlists.php From a.harrowell at gmail.com Mon Sep 15 04:22:27 2008 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Mon, 15 Sep 2008 10:22:27 +0100 Subject: Internet Traffic Begins to Bypass the U.S. In-Reply-To: <20080915061345.GA409@reptiles.org> References: <5.1.0.14.2.20080914084528.00adaeb8@efes.iucc.ac.il> <48CDA11D.2070407@vaxination.ca> <48CDA3D8.8030006@internode.com.au> <949b74980809141741h4261de3dx6ac2bb9f4c9f5420@mail.gmail.com> <20080915061345.GA409@reptiles.org> Message-ID: On Mon, Sep 15, 2008 at 7:13 AM, Jim Mercer wrote: > oddly enough, the ISP's in the region have not caught on to the potential > winfall of providing cost effective hosting locally, so therefore, the bulk > of the hosting for companies in the region is primarily done in the US, > then > in EU, then, maybe locally. > > if you drive down Sheikh Zayed Road in Dubai, and check where the hosting > is > for 90% of the URL's on the billboards (even those with .ae domains), you > will > find that they follow the above pattern. > > a primary example is that of du.ae, one of the only two > incumbent/dual-opoly > providers for the UAE, hosts its own website and customer portal in Canada, > even though it has a perfectly fine data center (if not more than one) in > Dubai. The political implications are interesting; the UAE has been more than keen to attract fibreoptic infrastructure, but setting up an IX would encourage local networks to interconnect without going via either Etisalat or Du, which has consequences both for their quasi-official monopoly and for the government's mass Internet filtering policy. There are (as you know Bob) already office developments that are allowed to have their own access to $World, and presumably there are networks in them; if they were allowed to interconnect with each other and with other networks, who knows? anarchy, cats and dogs making love in the streets, etc. Interestingly, other emerging markets did it the opposite way round. Kenya, frex, established an IX long before it had even the hope of submarine cable access. Now, with the new East African projects, there is talk of an Indian-style call centre/backoffice boom. From fw at deneb.enyo.de Mon Sep 15 04:23:15 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 15 Sep 2008 11:23:15 +0200 Subject: Internet Traffic Begins to Bypass the U.S. In-Reply-To: <48CDA11D.2070407@vaxination.ca> (=?iso-8859-1?Q?=22Jean-Fran?= =?iso-8859-1?Q?=E7ois?= Mezei"'s message of "Sun, 14 Sep 2008 19:41:17 -0400") References: <5.1.0.14.2.20080914084528.00adaeb8@efes.iucc.ac.il> <48CDA11D.2070407@vaxination.ca> Message-ID: <87ej3lu5j0.fsf@mid.deneb.enyo.de> * Jean-Fran?ois Mezei: > Did western europe ever really have a primary route via the USA to reach > asia ? It depends where you buy transit from. For instance, I see Baidu through AT&T, and the traffic is routed through the U.S. Some Singaporean banks and a few Koran government sites are routed through Level3, also via the U.S West coast. For sites in Thailand and Vietnam, the picture is a bit unclear (no visible IP hop in the U.S.). On another network, I reach Baidu through Telia, and it's still routed through the U.S. West coast. Both networks appear to see IIJ through a peering in San Jose. Anyway, at times, the more apt question would have been: Is Europe reachable from Europe without crossing the U.S.? I can't read the NYT story, but it seems highly unlikely to me that risk of eavesdropping on behalf of democratically elected governments is a factor in public Internet routing decisions. From jim at reptiles.org Mon Sep 15 04:40:14 2008 From: jim at reptiles.org (Jim Mercer) Date: Mon, 15 Sep 2008 05:40:14 -0400 Subject: Internet Traffic Begins to Bypass the U.S. In-Reply-To: References: <5.1.0.14.2.20080914084528.00adaeb8@efes.iucc.ac.il> <48CDA11D.2070407@vaxination.ca> <48CDA3D8.8030006@internode.com.au> <949b74980809141741h4261de3dx6ac2bb9f4c9f5420@mail.gmail.com> <20080915061345.GA409@reptiles.org> Message-ID: <20080915094014.GA15486@reptiles.org> On Mon, Sep 15, 2008 at 10:22:27AM +0100, Alexander Harrowell wrote: > On Mon, Sep 15, 2008 at 7:13 AM, Jim Mercer wrote: > > oddly enough, the ISP's in the region have not caught on to the potential > > winfall of providing cost effective hosting locally, so therefore, the bulk > > of the hosting for companies in the region is primarily done in the US, > > then in EU, then, maybe locally. > > The political implications are interesting; the UAE has been more than keen > to attract fibreoptic infrastructure, but setting up an IX would encourage > local networks to interconnect without going via either Etisalat or Du, > which has consequences both for their quasi-official monopoly and for the > government's mass Internet filtering policy. there is an exchange http://emix.ae, however, when i last interacted with them several years ago, it was a relatively closed club. that, and the actual exchange is located in Dubai (i think), which will require the arrangement of transit from the fiber drops (in Fujerah) to Dubai, at whatever rates etisalat (maybe du) decide to charge. the government filtering is not out of line with others in the region, and for the most part, doesn't hit political or religious sites, mostly porn, or sites that are reported to have porn (facebook/myspace/etc have all had their turn at being blocked, and then unblocked). > There are (as you know Bob) already office developments that are allowed to > have their own access to $World, and presumably there are networks in them; > if they were allowed to interconnect with each other and with other > networks, who knows? anarchy, cats and dogs making love in the streets, etc. nah, the perception that it is some kinda quasi-moral, quasi-authoratarian issue is wrong. its about money, period. they currently actively block anything VoIP related, and at points in the past, i ran into etisalat blocking access to sites containing voip-related forums/etc. generally the blockage is either for preserving their cash-flow (ie, no VoIP), or reactions to local-culture complaints about content, which allows them to maintain the high-moral ground with the local population, as "outsiders" wouldn't defend the local-culture. > Interestingly, other emerging markets did it the opposite way round. Kenya, > frex, established an IX long before it had even the hope of submarine cable > access. Now, with the new East African projects, there is talk of an > Indian-style call centre/backoffice boom. yep. as i was saying, the middle east region, with all of its potential capital, is overly protective of its incumbents to allow any kind of real competition. having lived here for some time, this tends to be true in alot of other market segments as well. if anyone from du or etisalat wishes to speak up and correct my impressions, please do. -- Jim Mercer jim at reptiles.org +971 55 410-5633 "I'm Prime Minister of Canada, I live here and I'm going to take a leak." - Lester Pearson in 1967, during a meeting between himself and President Lyndon Johnson, whose Secret Service detail had taken over Pearson's cottage retreat. At one point, a Johnson guard asked Pearson, "Who are you and where are you going?" From Rod.Beck at hiberniaatlantic.com Mon Sep 15 06:38:13 2008 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Mon, 15 Sep 2008 12:38:13 +0100 Subject: [SPAM-HEADER] - Re: Internet Traffic Begins to Bypass the U.S. - Email has different SMTP TO: and MIME TO: fields in the email addresses References: <5.1.0.14.2.20080914084528.00adaeb8@efes.iucc.ac.il><48CDA11D.2070407@vaxination.ca> <87ej3lu5j0.fsf@mid.deneb.enyo.de> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB169C6B@bert.HiberniaAtlantic.local> Fiber opic capacity from to Europe to Asia via the African cost has always been quite slim by TransAtlantic standards. As I recollect, you have FLAG, SWM3, and SWM4. Those systems can push multi-terabits. Capacity is not fundamentally the problem, but rather the lack of competition. Also you need a vibrantly competitive local loop market in these countries to drive undersea capacity demand. You don't have that yet, although it is emerging in countries like India. Regards, Roderick S. Beck Director of European Sales Hibernia Atlantic From tom at dyndns.com Mon Sep 15 07:14:06 2008 From: tom at dyndns.com (Tom Daly) Date: Mon, 15 Sep 2008 08:14:06 -0400 (EDT) Subject: Paging Level(3) Security Operations Message-ID: <17701795.43711221480846845.JavaMail.root@mail.corp.dyndns.com> Hello NANOG list, I'm trying to reach out to Level(3) Security Operations for assistance with a Denial of Service attack. So far, the normal means to contact Level(3) have failed. I can be reached directly at 603-296-1598. Thanks, Tom Daly -- Tom Daly tom at dyndns.com Dynamic Network Services, Inc. http://dynamicnetworkservices.com/ From JShao at dtcc.com Mon Sep 15 07:12:55 2008 From: JShao at dtcc.com (Jay Shao) Date: Mon, 15 Sep 2008 08:12:55 -0400 Subject: Jay Shao is out of the office. Message-ID: I will be out of the office starting 09/15/2008 and will not return until 09/21/2008. I will respond to your message when I return. Please contact with NETTCP at DTCC.COM for any production issues ----------------------------------------- ________________________________________________________ DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. From jabley at ca.afilias.info Mon Sep 15 07:36:25 2008 From: jabley at ca.afilias.info (Joe Abley) Date: Mon, 15 Sep 2008 08:36:25 -0400 Subject: Internet Traffic Begins to Bypass the U.S. In-Reply-To: <9F1A98CD-2A7C-4E47-B271-049D80B4FBCC@internode.com.au> References: <5.1.0.14.2.20080914084528.00adaeb8@efes.iucc.ac.il> <48CDA11D.2070407@vaxination.ca> <9F1A98CD-2A7C-4E47-B271-049D80B4FBCC@internode.com.au> Message-ID: On 14 Sep 2008, at 23:38, Matthew Moyle-Croft wrote: > Other cable systems predated FLAG (at least for voice). The qualifier might be important. As should have been obvious from all the IIRCs and related qualifiers in my note, I wasn't in Europe at the time I started paying attention to these things. However, in other parts of the world, circuits provisioned and planned for voice traffic growth started to become effectively full as soon as there was demand for circuits much bigger than an E1. As an example, PacRimEast still had capacity in the late 90s, strictly speaking. But given the difficulty in ordering anything other than E1s on it at that time, did it really exist as a terrestrial option for New Zealand ISPs trying to send packets to the US? There was a lot of satellite transmission sold around that time on PanAmSat, IntelSat and Loral transponders, and it's not as if anybody was really using satellite out of choice. There are only so many discrete E1s you can comfortably inverse-mux together before it's really not worth bothering. The timelines are no doubt different, since Europe experienced a giant boom in Internet demand and infrastructure while smaller markets like New Zealand were still preoccupied with X.25. However, the original question was whether there had ever been a time during which Europe had no option but to cross oceans to get to Asia, and I'd be surprised if that wasn't the case. Perhaps someone who actually knows this stuff can throw some facts into the thread and put a stop to my wild speculation. > SEA-ME-WE predates FLAG by almost a decade. I'm sure some digging > would reveal a bit more on that path either submarine or terrestrial. The contract to build SEA-ME-WE-4 was signed in March 2004, according to their web page. SEA-ME-WE-3 was commissioned in March 2000 in India, according to Wikipedia. The Europe-Asia segment of FLAG was lit in the mid-1990s. Joe From Rod.Beck at hiberniaatlantic.com Mon Sep 15 08:19:38 2008 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Mon, 15 Sep 2008 14:19:38 +0100 Subject: Internet Traffic Begins to Bypass the U.S. References: <5.1.0.14.2.20080914084528.00adaeb8@efes.iucc.ac.il> <48CDA11D.2070407@vaxination.ca> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB169C76@bert.HiberniaAtlantic.local> Hi Francois, The answer is yes. The cost of reaching Asian via the US was and is still much lower than via the cables that hug the Africain cost. And since Europe had a lot of traffic terminating in the US, it made more sense to throw it all that way than split into two major routes. Finally, a lot of European traffic is handed off to Asian backbones at the US West Coast peering points. There is no need to carry all the way to Asian since the Asian carriers have a huge presense at PAIX and other West Coast sites. 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 jabley at ca.afilias.info Mon Sep 15 09:39:28 2008 From: jabley at ca.afilias.info (Joe Abley) Date: Mon, 15 Sep 2008 10:39:28 -0400 Subject: Internet Traffic Begins to Bypass the U.S. In-Reply-To: <20080915094014.GA15486@reptiles.org> References: <5.1.0.14.2.20080914084528.00adaeb8@efes.iucc.ac.il> <48CDA11D.2070407@vaxination.ca> <48CDA3D8.8030006@internode.com.au> <949b74980809141741h4261de3dx6ac2bb9f4c9f5420@mail.gmail.com> <20080915061345.GA409@reptiles.org> <20080915094014.GA15486@reptiles.org> Message-ID: On 15 Sep 2008, at 05:40, Jim Mercer wrote: > there is an exchange http://emix.ae, however, when i last interacted > with > them several years ago, it was a relatively closed club. Unless things have changed recently, it's more of a monopoly transit provider than an exchange point. It's a service of Emirates Telecom/ Etisalat, AS8966; it's who people are obliged to buy transit from, there being no alternative for licensed ISPs. They do like to use the word "exchange" though, which can give the wrong impression. If it seems like a closed club, perhaps that's more of an ISP licensing issue in UAE than anything else. Joe From tomz at cisco.com Mon Sep 15 11:31:39 2008 From: tomz at cisco.com (Tom Zingale (tomz)) Date: Mon, 15 Sep 2008 09:31:39 -0700 Subject: Cisco uRPF failures In-Reply-To: <20080913182618.GA29660@biological.warningg.com> References: <4BE8B63C-3738-4161-AB69-08A5EAB4D7EE@netconsonance.com><00c401c9072b$f46a38c0$dd3eaa40$@com><007401c90e25$6eaf2280$4c0d6780$@com><6bb5f5b10809031906m67c18854nb4fe7260ad3e153@mail.gmail.com><5188BB8F-8EFC-4FCA-BA9F-E36E6C3CEB81@netconsonance.com><20080908085510.GA27179@mx.ytti.net><20080911171128.GA5283@mx.ytti.net> <20080913182618.GA29660@biological.warningg.com> Message-ID: The 3560E/3750E support uRPF as per docs: http://www.cisco.com/en/US/docs/switches/lan/catalyst3750e_3560e/softwar e/release/12.2_46_se/configuration/guide/swiprout.html#wp1388196 The unsupported command guide looks in error. > -----Original Message----- > From: Brandon Ewing [mailto:nicotine at warningg.com] > Sent: Saturday, September 13, 2008 11:26 AM > To: nanog at nanog.org; saku+nanog at ytti.fi > Subject: Re: Cisco uRPF failures > > On Thu, Sep 11, 2008 at 08:11:28PM +0300, Saku Ytti wrote: > > > > Sound like these shops are using 3550 as router, which is common for > > smaller shops, especially in EU. And indeed, 3550 would not do uRPF. > > (3560E does). > > > > Are you sure? According to the IOS guide for 3560E/3750E, "ip verify" > is > still an unsupported interface command. I don't have a 3560E handy to > test > on, but I know that a non-E 3560 refuses it with a notice regarding how > verification is not supported by hardware. > > http://tinyurl.com/5qbqzb > > -- > Brandon From msa at latt.net Mon Sep 15 13:05:39 2008 From: msa at latt.net (Majdi S. Abbas) Date: Mon, 15 Sep 2008 11:05:39 -0700 Subject: NANOG44 PGP Keysigning Message-ID: <20080915180538.GC84456@puck.nether.net> Greetings, For NANOG44 in Los Angeles, we will be running the keysigning sessions during the general session breaks in the Moroccan open seating area, which is on the Mezzanine level (above the Main Galleria). If you're planning to attend any of the keysigning sessions, please paste your keys into the keyring at: http://biglumber.com/x/web?keyring=2221 Also, if you do sign keys, whether or not you intend to attend one of the sessions, please do pick up a red sticker for your name tag when you pick it up. If you've never attended a PGP keysigning before, you may wish to review the following first for an understanding and overview of the process: http://www.cryptnet.net/fdp/crypto/keysigning_party/en/keysigning_party.html If you have any questions, please contact me off list. Thank you and I will see you in Los Angeles! --msa From Chris.Kleban at citrix.com Mon Sep 15 18:33:26 2008 From: Chris.Kleban at citrix.com (Chris Kleban) Date: Mon, 15 Sep 2008 16:33:26 -0700 Subject: Today's Point-2Point WAN Options Message-ID: <3C230BCB8BFE31408F4E0B95C26A618CB12A52F5@sbapexch05> Hello Nanog, I'm currently looking into what are the options for enabling inter-datacenter communication. Our current solution is to use ipsec/gre tunnels traversing over the Internet. The specific needs the new solution must meet are: - The ability to run end-to-end QOS. - Dedicated bandwidth - Support 1gbps transfer rates - Enable communication between 3 locations The options I have looked into so far are: - Layer 2 Ethernet (Virtual Private Line): This service seems to be offered by a lot of ISPs using various networking techniques. The price point is attractive however packets are forwarded only at best effort across the ISP's network which means the quality of the service will directly reflect the ISP's network performance. - Traditional Leased Line (dsX/ocX): This service seems to be more expensive then wavelength services however meets my needs. - WaveLength Services (oc3-10gig): This service seems to be cheaper then traditional leased lines when comparing similar bandwidth. However, availability is limited to on-net buildings. This solution meets my needs. - MPLS based VPN solutions: Seems to be a good point to multipoint technology with QOS offerings. However, the price seems to be around the same as wavelength services for the amount of bandwidth we require. If the number of data centers we were looking to connect was larger then this option would be more attractive. This solution meets my needs. Based on my needs and what my options are I am leaning towards point to point wavelength services connecting my 3 locations in a loop like fashion. Are there any other options I should consider? Are my descriptions of the today's possible solutions inaccurate? Are there any thoughts on today's pricing that differs then my findings? Thanks Chris Kleban From list-nanog at pwns.ms Mon Sep 15 18:55:20 2008 From: list-nanog at pwns.ms (list-nanog at pwns.ms) Date: Mon, 15 Sep 2008 23:55:20 +0000 Subject: Today's Point-2Point WAN Options In-Reply-To: <3C230BCB8BFE31408F4E0B95C26A618CB12A52F5@sbapexch05> References: <3C230BCB8BFE31408F4E0B95C26A618CB12A52F5@sbapexch05> Message-ID: <20080915235519.GA16854@pwns.ms> > - Layer 2 Ethernet (Virtual Private Line): This service seems to be offered by a lot of ISPs using various networking techniques. The price point is attractive however packets are forwarded only at best effort across the ISP's network which means the quality of the service will directly reflect the ISP's network performance. Depending on how it's implemented, it might have QoS in the ISPs network. If the ISP has plenty of bandwidth, best effort is fine. > - WaveLength Services (oc3-10gig): This service seems to be cheaper then traditional leased lines when comparing similar bandwidth. However, availability is limited to on-net buildings. This solution meets my needs. > - MPLS based VPN solutions: Seems to be a good point to multipoint technology with QOS offerings. However, the price seems to be around the same as wavelength services for the amount of bandwidth we require. If the number of data centers we were looking to connect was larger then this option would be more attractive. This solution meets my needs. Wavelengths are often sold without fibre redundancy; virtual links usually (I hope) have some redundant back haul, at least. Redundancy isn't necessarily good - the redundant path might be really, really bad. From pfs at cisco.com Mon Sep 15 18:34:28 2008 From: pfs at cisco.com (Philip Smith) Date: Tue, 16 Sep 2008 09:34:28 +1000 Subject: [NANOG-announce] Call for volunteers for the NANOG PC Message-ID: <48CEF104.4050805@cisco.com> Hi everyone, There are going to be a few announcements over the next few days regarding all things NANOG, so please bear with us! Thanks to all who volunteered for the Steering Committee - the list of candidates to join the three continuing Steering Committee members is at http://www.nanog.org/governance/elections/2008elections/2008sc_candidates.php. We will be holding elections during NANOG 44 in LA to determine who will join the Steering Committee. Now to the Program Committee! Here is your chance to help shape the future of the NANOG program content. NANOG Program Committee The NANOG Program Committee is a group of sixteen individuals from the NANOG community who together are responsible for the solicitation and selection of material for NANOG meeting Programs. A new NANOG Program Committee will be selected by the NANOG Steering Committee after the Steering Committee election in October. Eight positions are to be filled, and the Steering Committee is now seeking nominations. Per the NANOG charter (6.2.1), eligible candidates are individuals who have attended at least one NANOG meeting in the past 12 months (i.e. one or more of NANOG 42, NANOG 43 or NANOG 44). Broad technical knowledge of Internet operations and familiarity with NANOG meetings are useful attributes. Having constructive opinions and ideas about how NANOG meetings might be improved is of high value. If you are interested in nominating someone else or yourself, please send a brief note to nominations at nanog.org. The note should include the nominee's contact details, and a brief description of why (in your opinion) the individual concerned would be a good addition to the Program Committee. The Steering Committee will accept nominations received before the conclusion of NANOG 44 on October 14. If you would like to see a list of current nominations, please look at http://www.nanog.org/governance/elections/2008elections/2008pc_candidates.php. Many thanks, and hope to hear from you soon!! philip (for the SC) _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From mmc at internode.com.au Mon Sep 15 19:10:02 2008 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Tue, 16 Sep 2008 09:40:02 +0930 Subject: Internet Traffic Begins to Bypass the U.S. In-Reply-To: References: <5.1.0.14.2.20080914084528.00adaeb8@efes.iucc.ac.il> <48CDA11D.2070407@vaxination.ca> <9F1A98CD-2A7C-4E47-B271-049D80B4FBCC@internode.com.au> Message-ID: On 15/09/2008, at 10:06 PM, Joe Abley wrote: > > As an example, PacRimEast still had capacity in the late 90s, > strictly speaking. But given the difficulty in ordering anything > other than E1s on it at that time, did it really exist as a > terrestrial option for New Zealand ISPs trying to send packets to > the US? There was a lot of satellite transmission sold around that > time on PanAmSat, IntelSat and Loral transponders, and it's not as > if anybody was really using satellite out of choice. There are only > so many discrete E1s you can comfortably inverse-mux together before > it's really not worth bothering. Satellite was mainly because it was cheaper in a world where 2mbps out of Australia to the US cost US$150k/month. Circa around 1996 Telstra Internet had 16x2Mbps to the US plus 1x2Mbps to NZ. That didn't change until Southern Cross (SCCN) arrived in 2000. (I started in the ISP industry in 1994 in Australia, so whilst some of this is now a tad fuzzy, I was at least there for this bit. My home / 24 was 16 years old last month). > > > The timelines are no doubt different, since Europe experienced a > giant boom in Internet demand and infrastructure while smaller > markets like New Zealand were still preoccupied with X.25. However, > the original question was whether there had ever been a time during > which Europe had no option but to cross oceans to get to Asia, and > I'd be surprised if that wasn't the case. I guess it depends how far back you look in telecommunications history. The 1901 telegraph network was as extensive as today's submarine networks (if not broader) (http://atlantic-cable.com/Maps/1901EasternTelegraph.jpg ). Australia had telegraphy connectivity via Singapore and the All Red Route that the British ran and controlled since around 1879. > > Perhaps someone who actually knows this stuff can throw some facts > into the thread and put a stop to my wild speculation. > >> SEA-ME-WE predates FLAG by almost a decade. I'm sure some digging >> would reveal a bit more on that path either submarine or terrestrial. Before SEA-ME-WE4 and 3 there was SEA-ME-WE and SEA-ME-WE2. SEA-ME- WE had an inservice date of 1986. MMC -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc at internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909 From yahoo at jimpop.com Mon Sep 15 20:34:27 2008 From: yahoo at jimpop.com (Jim Popovitch) Date: Mon, 15 Sep 2008 21:34:27 -0400 Subject: confusing packet data Message-ID: <7ff145960809151834x66d18989q96015e3c3cfa9deb@mail.gmail.com> This is something has been bugging me lately.... Etherape is a Linux tool that graphs packets arriving at your host, and shows paths of connectivity. I captured the graphs, at the URL below, from my Linux laptop connected to a Linksys wifi router that is hooked to a Comcast cable modem. Why is it that I can see packet data from IPs all over the place? http://picasaweb.google.com/jimpop/Public# Any insight is much appreciated. -Jim P. From gih at apnic.net Mon Sep 15 20:42:28 2008 From: gih at apnic.net (Geoff Huston) Date: Tue, 16 Sep 2008 11:42:28 +1000 Subject: Internet Traffic Begins to Bypass the U.S. In-Reply-To: References: <5.1.0.14.2.20080914084528.00adaeb8@efes.iucc.ac.il> <48CDA11D.2070407@vaxination.ca> <9F1A98CD-2A7C-4E47-B271-049D80B4FBCC@internode.com.au> Message-ID: <87C78E39-BC70-4482-916F-0E31809DB105@apnic.net> On 15/09/2008, at 10:36 PM, Joe Abley wrote: > > On 14 Sep 2008, at 23:38, Matthew Moyle-Croft wrote: > >> Other cable systems predated FLAG (at least for voice). > > The qualifier might be important. > > As should have been obvious from all the IIRCs and related > qualifiers in my note, I wasn't in Europe at the time I started > paying attention to these things. However, in other parts of the > world, circuits provisioned and planned for voice traffic growth > started to become effectively full as soon as there was demand for > circuits much bigger than an E1. > > As an example, PacRimEast still had capacity in the late 90s, > strictly speaking. But given the difficulty in ordering anything > other than E1s on it at that time, did it really exist as a > terrestrial option for New Zealand ISPs trying to send packets to > the US? yes, for Australia, certainly. A number of us were using E1 inverse MUX units to pull higher channel rates out of the circuits. Same thing happened a few years later with muxing up 155Mbpsd circuits. > There was a lot of satellite transmission sold around that time on > PanAmSat, IntelSat and Loral transponders, and it's not as if > anybody was really using satellite out of choice. There are only so > many discrete E1s you can comfortably inverse-mux together before > it's really not worth bothering. heh heh - we ran out of cable capacity before we ran out of cascading inverse muxes at the time! Satellite really was a very inferior choice. > > The timelines are no doubt different, since Europe experienced a > giant boom in Internet demand and infrastructure while smaller > markets like New Zealand were still preoccupied with X.25. However, > the original question was whether there had ever been a time during > which Europe had no option but to cross oceans to get to Asia, and > I'd be surprised if that wasn't the case. The original telegraph circuits in the latter half of the 19th century were largely overland, but, unless there are markets you want to intercept with in the middle, undersea tends to be a better option where you consider all aspects (territorial rights, political issues, total length, stability etc etc). There was a very informative article by Neal Stephenson in Wired some years back that was published at about the time FLAG was being constructed which still is about the best article on the submarine cable business I've read. Everyone interested in this submarine cable game except Joe should read it. The problem with the routes in that part of the word include: the Wallace line, territorial waters, shallow waters, the Luzon strait, the stability of overland segments, the size of the markets in the middle, the cost and availability of the alternatives, and the major factor that spending 100% of your investment money to optimise 80% of your traffic needs makes more sense than many other investment strategies - hence the outcome that the Pacific has become the heavily favoured route for submarine cable systems in this area of the world. > > > Perhaps someone who actually knows this stuff can throw some facts > into the thread and put a stop to my wild speculation. nah - more fun to watch you speculate Joe. From nanog at daork.net Mon Sep 15 20:44:57 2008 From: nanog at daork.net (Nathan Ward) Date: Tue, 16 Sep 2008 13:44:57 +1200 Subject: confusing packet data In-Reply-To: <7ff145960809151834x66d18989q96015e3c3cfa9deb@mail.gmail.com> References: <7ff145960809151834x66d18989q96015e3c3cfa9deb@mail.gmail.com> Message-ID: <68F11B81-E578-4CD8-B335-FE495473CE9D@daork.net> On 16/09/2008, at 1:34 PM, Jim Popovitch wrote: > This is something has been bugging me lately.... Etherape is a Linux > tool that graphs packets arriving at your host, and shows paths of > connectivity. I captured the graphs, at the URL below, from my Linux > laptop connected to a Linksys wifi router that is hooked to a Comcast > cable modem. Why is it that I can see packet data from IPs all over > the place? My suspicion is that the tool is malfunctioning and is spitting out random data. Probably best to post on the Etherape mailing list for help on this one. I see stuff in 224/4 and 240/4 in your pictures. -- Nathan Ward From pauldotwall at gmail.com Mon Sep 15 21:33:05 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Mon, 15 Sep 2008 22:33:05 -0400 Subject: Today's Point-2Point WAN Options In-Reply-To: <3C230BCB8BFE31408F4E0B95C26A618CB12A52F5@sbapexch05> References: <3C230BCB8BFE31408F4E0B95C26A618CB12A52F5@sbapexch05> Message-ID: <620fd17c0809151933k61a41be7t77e21c892584e9cd@mail.gmail.com> Chris Kleban wrote: > Hello Nanog, > > I'm currently looking into what are the options for enabling inter-datacenter communication. > > Our current solution is to use ipsec/gre tunnels traversing over the Internet. The specific needs the new solution must meet are: > > - The ability to run end-to-end QOS. What are you trying to accomplish? Do you need to be able to pass DiffServ/DSCP tagging between sites? > - Dedicated bandwidth > - Support 1gbps transfer rates > - Enable communication between 3 locations Okay. > The options I have looked into so far are: > > - Layer 2 Ethernet (Virtual Private Line): This service seems to be offered by a lot of ISPs using various networking techniques. The price point is attractive however packets are forwarded only at best effort across the ISP's network which means the quality of the service will directly reflect the ISP's network performance. How is this a problem? Is that concern that you never want an interface which is (physically, to routing protocols, ...) "up" but latent and dropping packets like whoa, from an application or monitoring/management prospective? You raise a valid point about oversubscription. At the same time, this is often overhyped by marketing people, and dependent on how ghetto your pseudowire provider is and whether or not they know how to capacity-plan. > - Traditional Leased Line (dsX/ocX): This service seems to be more expensive then wavelength services however meets my needs. Quite. And it limits your router options significantly while driving up capex costs. Just say no! > - WaveLength Services (oc3-10gig): This service seems to be cheaper then traditional leased lines when comparing similar bandwidth. However, availability is limited to on-net buildings. This solution meets my needs. Not a bad idea, but often overlooked when purchasing unprotected long-haul waves is that you can be down for days or weeks on end, depending on the severity of a given fiber cut. And protected waves cost significantly more because the carrier is provisioning twice the capacity -- sometimes in a configuration not as redundant as advertised. This is not for the faint of heart, and best left to ISPs who are buying from multiple vendors/cable systems and put in the effort to engineer suitable diversity. As an end-user, a switched service might afford you more economical route protection. > - MPLS based VPN solutions: Seems to be a good point to multipoint technology with QOS offerings. However, the price seems to be around the same as wavelength services for the amount of bandwidth we require. If the number of data centers we were looking to connect was larger then this option would be more attractive. This solution meets my needs. (Assuming you're talking about l3vpn, as l2 can be grouped into your first example...) It would probably help if you'd explain the "QOS" feature set of the offerings you're looking at. This is a highly technically complex deployment; even at the largest telecoms, you can count on one hand the number of staff expert in its implementation and troubleshooting. It's also the most limiting in terms of specific routing protocols and prefix counts supported, the type of traffic you can pass, etc. The only benefit I can see to a l3vpn is in the enterprise with a lot of branch offices, where it simplifies end-site configurations and hub/spoke topology. Connecting your three datacenters, this is obviously not an issue. These are often the most expensive solutions too, given that their target customers have deep pockets. > Based on my needs and what my options are I am leaning towards point to point wavelength services connecting my 3 locations in a loop like fashion. > > > Are there any other options I should consider? None come to mind. > Are my descriptions of the today's possible solutions inaccurate? More or less, though it would help if you'd explain more what you're trying to get out of the "QOS". Best Of Luck, and Drive Slow, Paul Wall From pauldotwall at gmail.com Mon Sep 15 21:37:24 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Mon, 15 Sep 2008 22:37:24 -0400 Subject: Atrivo/Intercage: Now Only 1 Upstream In-Reply-To: <20080915.003251.7577.3@webmail03.vgs.untd.com> References: <20080915.003251.7577.3@webmail03.vgs.untd.com> Message-ID: <620fd17c0809151937k247ccc79j1101b42866b7a960@mail.gmail.com> Paul, Cogent is keeping tabs of the Intercage/Atrivo situation in ticket HD0000000789038. Be sure to e-mail or call them referencing that number with any information you may have to share. AboveNet's ticket auto-responder is broken. I've been unable to get a response out of NTT (AS 2914). Drive Slow, Paul Wall From hank at efes.iucc.ac.il Mon Sep 15 23:43:44 2008 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 16 Sep 2008 07:43:44 +0300 (IDT) Subject: confusing packet data In-Reply-To: <7ff145960809151834x66d18989q96015e3c3cfa9deb@mail.gmail.com> References: <7ff145960809151834x66d18989q96015e3c3cfa9deb@mail.gmail.com> Message-ID: On Mon, 15 Sep 2008, Jim Popovitch wrote: Are you running Skype? Have you become a supernode? There is now a registry switch in 3.0 that allows you to disable supernode functionality. -Hank > This is something has been bugging me lately.... Etherape is a Linux > tool that graphs packets arriving at your host, and shows paths of > connectivity. I captured the graphs, at the URL below, from my Linux > laptop connected to a Linksys wifi router that is hooked to a Comcast > cable modem. Why is it that I can see packet data from IPs all over > the place? > > http://picasaweb.google.com/jimpop/Public# > > Any insight is much appreciated. > > -Jim P. > From nanog at daork.net Mon Sep 15 23:47:01 2008 From: nanog at daork.net (Nathan Ward) Date: Tue, 16 Sep 2008 16:47:01 +1200 Subject: confusing packet data In-Reply-To: References: <7ff145960809151834x66d18989q96015e3c3cfa9deb@mail.gmail.com> Message-ID: <8E436664-9B9E-4EC8-ABBC-1EA935643708@daork.net> On 16/09/2008, at 4:43 PM, Hank Nussbacher wrote: > Are you running Skype? Have you become a supernode? There is now a > registry switch in 3.0 that allows you to disable supernode > functionality. This would not cause him to see traffic to and from random addresses. Note that traffic is not going to his IP address, but to AND from addresses that are not his. That, plus the fact that there 'is' traffic on 240/4 and 224/4, and it sounds like a bug. -- Nathan Ward From yahoo at jimpop.com Mon Sep 15 23:47:33 2008 From: yahoo at jimpop.com (Jim Popovitch) Date: Tue, 16 Sep 2008 00:47:33 -0400 Subject: confusing packet data In-Reply-To: References: <7ff145960809151834x66d18989q96015e3c3cfa9deb@mail.gmail.com> Message-ID: <7ff145960809152147k3fd74511h6bb261abdb78cd6d@mail.gmail.com> On Tue, Sep 16, 2008 at 00:43, Hank Nussbacher wrote: > Are you running Skype? Have you become a supernode? There is now a > registry switch in 3.0 that allows you to disable supernode functionality. No. Nothing is running on this host (my laptop) when initiating etherape. Also, etherape reports nothing until I initiate some traffic (i.e. whois www.yahoo.com) I suspect that Nathan is correct and I have filed a bug report with Debian. -Jim P. From fergdawg at netzero.net Tue Sep 16 00:11:08 2008 From: fergdawg at netzero.net (Paul Ferguson) Date: Tue, 16 Sep 2008 05:11:08 GMT Subject: Atrivo/Intercage: Now Only 1 Upstream Message-ID: <20080915.221108.11853.0@webmail15.vgs.untd.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- "Paul Wall" wrote: >Cogent is keeping tabs of the Intercage/Atrivo situation in ticket >HD0000000789038. Be sure to e-mail or call them referencing that >number with any information you may have to share. > >AboveNet's ticket auto-responder is broken. > I don't have time to pass along intelligence to Cogent, and if I did feel so inclined, somehow I get the feeling that I would largely be ignored since I'm not a direct customer. I'm more inclined to pass along the intelligence to law enforcement, as many of us have been doing for a couple of years now. In any event, the badness is still there. Lots of it. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFIzz/jq1pz9mNUZTMRAoykAKDT0Z9j7zw8RHpO0fSjBIYdbUCTiACg3koi F2OWk5qP+5ZsXdBbBcg6cB4= =Mfgg -----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 hank at efes.iucc.ac.il Tue Sep 16 00:46:33 2008 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 16 Sep 2008 08:46:33 +0300 (IDT) Subject: Atrivo/Intercage: Now Only 1 Upstream In-Reply-To: <20080915.221108.11853.0@webmail15.vgs.untd.com> References: <20080915.221108.11853.0@webmail15.vgs.untd.com> Message-ID: On Tue, 16 Sep 2008, Paul Ferguson wrote: > In any event, the badness is still there. Lots of it. Not according to this: http://www.domainnews.com/en/general/estdomains-denies-links-to-malware-distribution.html "The company also has a reliable ally in its battle against malware in a face of Intercage, Inc which provides company with the hosting services of the highest quality. But the outstanding performance of hosting services is not the sole reason why EstDomains, Inc appreciates this partnership so greatly. Intercage, Inc generously provides EstDomains, Inc specialists with reports regarding discovered malware vehicles. As the main database for additional domain name management services is located in Intercage Data Center, EstDomains, Inc has the perfect opportunity to get notifications of the slightest mark of malware presence in the shortest time and take measures in advance." You really need to read the entire posting and not end up ROTFL. -Hank From fergdawg at netzero.net Tue Sep 16 00:55:08 2008 From: fergdawg at netzero.net (Paul Ferguson) Date: Tue, 16 Sep 2008 05:55:08 GMT Subject: Atrivo/Intercage: Now Only 1 Upstream Message-ID: <20080915.225508.11853.1@webmail15.vgs.untd.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- "Paul Wall" wrote: >Cogent is keeping tabs of the Intercage/Atrivo situation in ticket >HD0000000789038. Be sure to e-mail or call them referencing that >number with any information you may have to share. > >AboveNet's ticket auto-responder is broken. > By the way, a lot of folks are watching all domains registered within Atrivo/Intercage IP address space every day. Here's a few for you to decide -- and they have been registered only in the past few days: undaground.biz pillshere.net ukrnic.info (originally registered in Intercage IP space, now in UkrTelecom) This is only a fraction of a percentage of the activities. We are watching. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFIz0ozq1pz9mNUZTMRAnHeAJ4ntfwfiQaQxhTXfs89uo2I3cTJMgCfb41s M7q+r1sgTSmGL1+vszyHYb0= =c6jO -----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 lionair at samsung.com Tue Sep 16 02:40:10 2008 From: lionair at samsung.com (ChiYoung Joung) Date: Tue, 16 Sep 2008 07:40:10 +0000 (GMT) Subject: Anyone know Wiltel's EWAN service Message-ID: <29577470.90361221550810696.JavaMail.weblogic@epml08> I have EWAN circuits of Wiltel(currently same company with Level3 you know) as my backbone circuit in LA. About 2 months ago, there were some packet loss on L2 circuit, but I didn't get any clear answer from Level3 support center. It became okey without any action, but now, same problem happen again. I feel bored, I need your help. Anyone know if there are any problems of WilTel's L2 circuit on LA area ? or Could anyone advice me the contact person who know well EWAN configuration of Wiltel ? Frankly, I felt Level3 guys seems to be unfamiliar with EWAN circuit of Wiltel. Best regards, Chiyoung ============================================= Chi-Young Joung SAMSUNG NETWORKS Inc. Email: lionair at samsung.com Tel +82 70 7015 0623, Mobile +82 17 520 9193 Fax +82 70 7016 0031 ============================================= From president at ukraine.su Tue Sep 16 04:18:40 2008 From: president at ukraine.su (Max Tulyev) Date: Tue, 16 Sep 2008 12:18:40 +0300 Subject: Internet Traffic Begins to Bypass the U.S. In-Reply-To: <48CDA11D.2070407@vaxination.ca> References: <5.1.0.14.2.20080914084528.00adaeb8@efes.iucc.ac.il> <48CDA11D.2070407@vaxination.ca> Message-ID: <48CF79F0.1060808@ukraine.su> Jean-Fran?ois Mezei wrote: > Did western europe ever really have a primary route via the USA to reach > asia ? (I realise that during the cable cuts in middle east last year, > traffic might have been rerouted via USA but this would be a temporary > situation). Yes. And the main issue is not technical, but economic and disorganisation question. For example, we need an Internet connectivity in Kazakhstan. The path through TAE (www.taeint.net) or FLAG-Iran-Turkmenistan-Uzbekistan costs about $6000 per 1Mbit, and lot of nervous. Path through China-USA is said about $100-$400 per 1Mbps and easy to get comparing with first two ones.. Yes, Europe-Asia satellites is a good way too, and it can give less latency than Europe-USA-Asia in some cases. A lot of traffic to Asia and Middle East is going this way. But satellite is expensive, and there is even lack of capacity there. So Fiber around the world is cheaper in most cases. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From erikpsundberg at gmail.com Tue Sep 16 04:31:18 2008 From: erikpsundberg at gmail.com (Erik Sundberg) Date: Tue, 16 Sep 2008 04:31:18 -0500 Subject: ATT AS7018 turnup BGP issue Message-ID: Can someone from ATT with BGP configuration access please contact me off list, the provisioning group has been having trouble turnup our BGP session on our 2xOC3 to AS7018 since 12AM and now its 4:30AM. Erik esundberg at cimco.net From patrick at ianai.net Tue Sep 16 05:01:16 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 16 Sep 2008 06:01:16 -0400 Subject: Atrivo/Intercage: Now Only 1 Upstream In-Reply-To: <20080915.225508.11853.1@webmail15.vgs.untd.com> References: <20080915.225508.11853.1@webmail15.vgs.untd.com> Message-ID: On Sep 16, 2008, at 1:55 AM, Paul Ferguson wrote: > By the way, a lot of folks are watching all domains registered > within Atrivo/Intercage IP address space every day. Here's a few > for you to decide -- and they have been registered only in the past > few days: > > undaground.biz > pillshere.net > ukrnic.info (originally registered in Intercage IP space, now > in UkrTelecom) > > This is only a fraction of a percentage of the activities. > > We are watching. Not closely enough. It seems some people in San Francisco are selling Intercage outbound only capacity. (I.e. Letting them send packets and not announcing their ASN/prefixes to hide the fact Atrivo is a customer.) If you find packets from Atrivo coming into your network from a network where you do not see a reverse path, please let the rest of us know so we can take appropriate action. -- TTFN, patrick From castellan2004-nsm at yahoo.com Tue Sep 16 05:03:59 2008 From: castellan2004-nsm at yahoo.com (castellan2004-nsm at yahoo.com) Date: Tue, 16 Sep 2008 03:03:59 -0700 (PDT) Subject: Creating a visual Map of a network? Message-ID: <451268.84305.qm@web30807.mail.mud.yahoo.com> I am being tasked to map a network. In the past I have used nmap to find the systems on the local LAN and remote LANs (same enterprise). This time I want to create a visual map of the LAN. With cheops, I reasonably good results but cannot be documented for managers with certainty. What are some good tools now that will create visual maps of the networks? What is the best way to map a network when ICMP echo has been turned off? Thank you in advance for any help. Subba Rao From Rod.Beck at hiberniaatlantic.com Tue Sep 16 05:09:18 2008 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Tue, 16 Sep 2008 11:09:18 +0100 Subject: [SPAM-HEADER] - Today's Point-2Point WAN Options - Email has different SMTP TO: and MIME TO: fields in the email addresses References: <3C230BCB8BFE31408F4E0B95C26A618CB12A52F5@sbapexch05> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB169C92@bert.HiberniaAtlantic.local> Actually, it is not true that Layer 2 Ethernet is 'best effort'. It depends. There are Layer 1 Ethernet products that involve no Layer 2 switching or Layer 2 routing, just an efficient and transparent mapping of Ethernet into SDH/SONET. And some of those products can be upgrade in 50 meg increments from 100 to 1,000 megs. After you have outgrown your GigE, then you can migrate to a LAN PHY 10 GigE link using affordable LAN interfaces and keeping your network 'untainted' by SONET/SDH. 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. -----Original Message----- From: Chris Kleban [mailto:Chris.Kleban at citrix.com] Sent: Tue 9/16/2008 12:33 AM To: nanog at nanog.org Subject: [SPAM-HEADER] - Today's Point-2Point WAN Options - Email has different SMTP TO: and MIME TO: fields in the email addresses Hello Nanog, I'm currently looking into what are the options for enabling inter-datacenter communication. Our current solution is to use ipsec/gre tunnels traversing over the Internet. The specific needs the new solution must meet are: - The ability to run end-to-end QOS. - Dedicated bandwidth - Support 1gbps transfer rates - Enable communication between 3 locations The options I have looked into so far are: - Layer 2 Ethernet (Virtual Private Line): This service seems to be offered by a lot of ISPs using various networking techniques. The price point is attractive however packets are forwarded only at best effort across the ISP's network which means the quality of the service will directly reflect the ISP's network performance. - Traditional Leased Line (dsX/ocX): This service seems to be more expensive then wavelength services however meets my needs. - WaveLength Services (oc3-10gig): This service seems to be cheaper then traditional leased lines when comparing similar bandwidth. However, availability is limited to on-net buildings. This solution meets my needs. - MPLS based VPN solutions: Seems to be a good point to multipoint technology with QOS offerings. However, the price seems to be around the same as wavelength services for the amount of bandwidth we require. If the number of data centers we were looking to connect was larger then this option would be more attractive. This solution meets my needs. Based on my needs and what my options are I am leaning towards point to point wavelength services connecting my 3 locations in a loop like fashion. Are there any other options I should consider? Are my descriptions of the today's possible solutions inaccurate? Are there any thoughts on today's pricing that differs then my findings? Thanks Chris Kleban From karnaugh at karnaugh.za.net Tue Sep 16 05:41:41 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Tue, 16 Sep 2008 12:41:41 +0200 Subject: Creating a visual Map of a network? In-Reply-To: <451268.84305.qm@web30807.mail.mud.yahoo.com> References: <451268.84305.qm@web30807.mail.mud.yahoo.com> Message-ID: <48CF8D65.6090408@karnaugh.za.net> castellan2004-nsm at yahoo.com wrote: > I am being tasked to map a network. In the past I have used nmap to find the systems on the local LAN and remote LANs (same enterprise). > > This time I want to create a visual map of the LAN. With cheops, I reasonably good results but cannot be documented for managers with certainty. What are some good tools now that will create visual maps of the networks? > > What is the best way to map a network when ICMP echo has been turned off? > I've had success using Scapy (http://www.secdev.org/projects/scapy/) and tying it into Graphviz. It can do TCP traces too and has all sorts of built in visualisation options. And look at the bottom here http://www.secdev.org/projects/scapy/demo.html From erikpsundberg at gmail.com Tue Sep 16 05:54:49 2008 From: erikpsundberg at gmail.com (Erik Sundberg) Date: Tue, 16 Sep 2008 05:54:49 -0500 Subject: ATT BGP turnup issue -- FIXED Message-ID: <48cf9077.2009360a.2304.ffffebdf@mx.google.com> This issue was finally resolved by ATT.. No need to contact me... Thanks Erik From darden at armc.org Tue Sep 16 07:00:18 2008 From: darden at armc.org (Darden, Patrick S.) Date: Tue, 16 Sep 2008 08:00:18 -0400 Subject: confusing packet data In-Reply-To: <8E436664-9B9E-4EC8-ABBC-1EA935643708@daork.net> Message-ID: Or his DSL is set to bridging. --p -----Original Message----- From: Nathan Ward [mailto:nanog at daork.net] Sent: Tuesday, September 16, 2008 12:47 AM To: nanog list Subject: Re: confusing packet data On 16/09/2008, at 4:43 PM, Hank Nussbacher wrote: > Are you running Skype? Have you become a supernode? There is now a > registry switch in 3.0 that allows you to disable supernode > functionality. This would not cause him to see traffic to and from random addresses. Note that traffic is not going to his IP address, but to AND from addresses that are not his. That, plus the fact that there 'is' traffic on 240/4 and 224/4, and it sounds like a bug. -- Nathan Ward From mrp at mrp.net Tue Sep 16 08:15:36 2008 From: mrp at mrp.net (Mark Prior) Date: Tue, 16 Sep 2008 22:45:36 +0930 Subject: Internet Traffic Begins to Bypass the U.S. In-Reply-To: <48CDB76A.3030009@vaxination.ca> References: <5.1.0.14.2.20080914084528.00adaeb8@efes.iucc.ac.il> <48CDA11D.2070407@vaxination.ca> <48CDA3D8.8030006@internode.com.au> <48CDB76A.3030009@vaxination.ca> Message-ID: <48CFB178.8020808@mrp.net> Jean-Fran?ois Mezei wrote: >> For instance, out of Australia we have a single, old cable going West >> out of Perth to Singapore (SEA-ME-WE3) which allows only low speed >> circuits, > > Was there any thought about building cables to singapore from darwin now > that it has had fibre links to the rest of australia for over a decade ? There are two old cable systems heading out from Western Australia (MMC forgot JASURAUS). Darwin is a monopoly zone, only Telstra have capacity into it although others have thought about it (assuming the government stumps up some cash). The technical issue with submarine cables out of Darwin is avoiding the Timor Trench. It makes more sense for a lot of reasons to head out of Perth if you want to go west. Mark. From Mauricio.Rodriguez at fpl.com Tue Sep 16 08:29:15 2008 From: Mauricio.Rodriguez at fpl.com (Rodriguez, Mauricio) Date: Tue, 16 Sep 2008 09:29:15 -0400 Subject: LoA (Letter of Authorization) for Prefix Filter Modification? Message-ID: Recently, one of our Transit providers has started requiring a Letter of Authorization for addition of any of our own Transit customers' prefixes to their filters. The verbiage of the LoA basically states that the owner of the assignment or allocation (not necessarily our customer) allows us to advertise their prefixes through our service. Is this a common practice? Our past experience indicates that a simple request to a NOC or update of a routing registry usually is sufficient. Regards, Mauricio Rodriguez FPL Fibernet, LLC From charles at thewybles.com Tue Sep 16 08:44:43 2008 From: charles at thewybles.com (charles at thewybles.com) Date: Tue, 16 Sep 2008 13:44:43 +0000 Subject: Anyone know Wiltel's EWAN service Message-ID: <316009879-1221572738-cardhu_decombobulator_blackberry.rim.net-1142348229-@bxe190.bisx.prod.on.blackberry> La as in Los Angeles? Or Louisiana? There we're numerous strange issues last night in Los Angeles with T-Mobile that were caused by att loosing some oc12 circuits. That could have affected other carriers I'm sure. ------Original Message------ From: ChiYoung Joung To: nanog ReplyTo: lionair at samsung.com Subject: Anyone know Wiltel's EWAN service Sent: Sep 16, 2008 12:40 AM I have EWAN circuits of Wiltel(currently same company with Level3 you know) as my backbone circuit in LA. About 2 months ago, there were some packet loss on L2 circuit, but I didn't get any clear answer from Level3 support center. It became okey without any action, but now, same problem happen again. I feel bored, I need your help. Anyone know if there are any problems of WilTel's L2 circuit on LA area ? or Could anyone advice me the contact person who know well EWAN configuration of Wiltel ? Frankly, I felt Level3 guys seems to be unfamiliar with EWAN circuit of Wiltel. Best regards, Chiyoung ============================================= Chi-Young Joung SAMSUNG NETWORKS Inc. Email: lionair at samsung.com Tel +82 70 7015 0623, Mobile +82 17 520 9193 Fax +82 70 7016 0031 ============================================= Sent via BlackBerry from T-Mobile From jlewis at lewis.org Tue Sep 16 08:56:16 2008 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 16 Sep 2008 09:56:16 -0400 (EDT) Subject: LoA (Letter of Authorization) for Prefix Filter Modification? In-Reply-To: References: Message-ID: On Tue, 16 Sep 2008, Rodriguez, Mauricio wrote: > Recently, one of our Transit providers has started requiring a Letter of > Authorization for addition of any of our own Transit customers' prefixes > to their filters. The verbiage of the LoA basically states that the > owner of the assignment or allocation (not necessarily our customer) > allows us to advertise their prefixes through our service. > > Is this a common practice? Our past experience indicates that a simple > request to a NOC or update of a routing registry usually is sufficient. It's not unheard of. Most providers don't require it, but I have run into a few who do. It's a minor PITA compared to the web interfaces some providers make you use to request filter updates. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From hobbit at avian.org Tue Sep 16 07:47:26 2008 From: hobbit at avian.org (*Hobbit*) Date: Tue, 16 Sep 2008 12:47:26 +0000 (GMT) Subject: Atrivo/Intercage: Now Only 1 Upstream Message-ID: <20080916124726.34FF67809@relayer.avian.org> So in cases like this where the community appears to agree that there's a consistently bad apple, what's preventing everyone from simply nullrouting the netblocks in question and imposing the death penalty? Sorry if this seems naive, but if no legitimate purpose is shown it seems like the obvious thing to do. Maybe they could still *send* packets, but nothing would ever get back to them. _H* From christian at broknrobot.com Tue Sep 16 09:02:29 2008 From: christian at broknrobot.com (Christian Koch) Date: Tue, 16 Sep 2008 10:02:29 -0400 Subject: LoA (Letter of Authorization) for Prefix Filter Modification? In-Reply-To: References: Message-ID: I dont mind, i think it is another good step towards 'good filtering' but...i think the PITA part is downstream 'clueless' customers, who may need an explanation on prefix hijacking and the state of the internet today, and that these are all just combined efforts to minimize the risk of accepting allocations that don't belong to you. Christian On Tue, Sep 16, 2008 at 9:56 AM, Jon Lewis wrote: > On Tue, 16 Sep 2008, Rodriguez, Mauricio wrote: > >> Recently, one of our Transit providers has started requiring a Letter of >> Authorization for addition of any of our own Transit customers' prefixes to >> their filters. The verbiage of the LoA basically states that the owner of >> the assignment or allocation (not necessarily our customer) allows us to >> advertise their prefixes through our service. >> >> Is this a common practice? Our past experience indicates that a simple >> request to a NOC or update of a routing registry usually is sufficient. > > It's not unheard of. Most providers don't require it, but I have run into a > few who do. It's a minor PITA compared to the web interfaces some providers > make you use to request filter updates. > > > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > > From repstein at chello.at Tue Sep 16 09:10:05 2008 From: repstein at chello.at (Randy Epstein) Date: Tue, 16 Sep 2008 10:10:05 -0400 Subject: LoA (Letter of Authorization) for Prefix Filter Modification? In-Reply-To: References: Message-ID: <0CA061F473C240C397D76128EFF41E81@D88CFA77634F40F> >Is this a common practice? Our past experience indicates that a simple >request to a NOC or update of a routing registry usually is sufficient. > >Regards, >Mauricio Rodriguez >FPL Fibernet, LLC Cogent AFAIK have been doing this for years. Not many others require this unless there is a serious question over the request. Randy From jlewis at lewis.org Tue Sep 16 09:24:35 2008 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 16 Sep 2008 10:24:35 -0400 (EDT) Subject: LoA (Letter of Authorization) for Prefix Filter Modification? In-Reply-To: References: Message-ID: On Tue, 16 Sep 2008, Christian Koch wrote: > I dont mind, i think it is another good step towards 'good filtering' > but...i think the PITA part is > downstream 'clueless' customers, who may need an explanation on prefix > hijacking and the state > of the internet today, and that these are all just combined efforts to > minimize the risk of accepting allocations > that don't belong to you. IMO, it's just an illusion of added security and is really just CYA for the provider. When I fax TWTelecom an LOA that a customer faxed to me, how does TWTelecom verify the authenticity of that LOA? I doubt they try. I suspect it's just filed, and will only be pulled out if the advertisement is challenged by some 3rd party. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From christian at broknrobot.com Tue Sep 16 09:33:42 2008 From: christian at broknrobot.com (Christian Koch) Date: Tue, 16 Sep 2008 10:33:42 -0400 Subject: LoA (Letter of Authorization) for Prefix Filter Modification? In-Reply-To: References: Message-ID: good point... :) On Tue, Sep 16, 2008 at 10:24 AM, Jon Lewis wrote: > On Tue, 16 Sep 2008, Christian Koch wrote: > >> I dont mind, i think it is another good step towards 'good filtering' >> but...i think the PITA part is >> downstream 'clueless' customers, who may need an explanation on prefix >> hijacking and the state >> of the internet today, and that these are all just combined efforts to >> minimize the risk of accepting allocations >> that don't belong to you. > > IMO, it's just an illusion of added security and is really just CYA for the > provider. When I fax TWTelecom an LOA that a customer faxed to me, how does > TWTelecom verify the authenticity of that LOA? I doubt they try. I suspect > it's just filed, and will only be pulled out if the advertisement is > challenged by some 3rd party. > > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > From lionair at samsung.com Tue Sep 16 09:40:15 2008 From: lionair at samsung.com (=?euc-kr?B?waTEob+1?=) Date: Tue, 16 Sep 2008 14:40:15 +0000 (GMT) Subject: Anyone know Wiltel's EWAN service Message-ID: <7406696.107151221576015192.JavaMail.weblogic@epml07> Sorry, it is Los Angeles. I don't know whether our circuit is ralative to ATT oc12 ============================================= Chi-Young Joung SAMSUNG NETWORKS Inc. Email: lionair at samsung.com Tel +82 70 7015 0623, Mobile +82 17 520 9193 Fax +82 70 7016 0031 ============================================= ------- Original Message ------- Sender : charles at thewybles.com Date : 2008-09-16 22:44 (GMT+09:00) Title : Re: Anyone know Wiltel's EWAN service La as in Los Angeles? Or Louisiana? There we're numerous strange issues last night in Los Angeles with T-Mobile that were caused by att loosing some oc12 circuits. That could have affected other carriers I'm sure. ------Original Message------ From: ChiYoung Joung To: nanog ReplyTo: lionair at samsung.com Subject: Anyone know Wiltel's EWAN service Sent: Sep 16, 2008 12:40 AM I have EWAN circuits of Wiltel(currently same company with Level3 you know) as my backbone circuit in LA. About 2 months ago, there were some packet loss on L2 circuit, but I didn't get any clear answer from Level3 support center. It became okey without any action, but now, same problem happen again. I feel bored, I need your help. Anyone know if there are any problems of WilTel's L2 circuit on LA area ? or Could anyone advice me the contact person who know well EWAN configuration of Wiltel ? Frankly, I felt Level3 guys seems to be unfamiliar with EWAN circuit of Wiltel. Best regards, Chiyoung ============================================= Chi-Young Joung SAMSUNG NETWORKS Inc. Email: lionair at samsung.com Tel +82 70 7015 0623, Mobile +82 17 520 9193 Fax +82 70 7016 0031 ============================================= Sent via BlackBerry from T-Mobile From info at arin.net Tue Sep 16 09:46:49 2008 From: info at arin.net (Member Services) Date: Tue, 16 Sep 2008 10:46:49 -0400 Subject: IPv6 Penetration Survey: Your Participation Requested Message-ID: <48CFC6D9.1050104@arin.net> The American Registry for Internet Numbers (ARIN), in cooperation with the Cooperative Association for Internet Data Analysis (CAIDA), is conducting a new survey to gather data regarding current and future use of IPv6. We have expanded the scope of the survey to seek IPv6 penetration data from around the world. We cordially invite and encourage all organizations in the AfriNIC, APNIC, ARIN, LACNIC, and RIPE NCC regions to participate in the survey so we can establish a comprehensive view of present IPv6 penetration and future plans for IPv6 deployment. The survey opened on 8 September and remains available until 17:00 EDT on 1 October. The results of the survey will be presented and discussed at the ARIN XXII Public Policy and Members Meeting to be held in Los Angeles, CA 15-17 October 2008. Additionally, the summary results will be shared with all the RIRs for further distribution within their respective regions. The survey data will support ongoing research. The survey is composed of 22 questions that can be answered in a few minutes. This is a secure survey and all data will be presented in summary form only, and kept confidential between ARIN and CAIDA. When you complete the survey you will be entered in a drawing for prizes, one raffle per RIR region. You must provide your contact information to win. Please take a few moments to complete the survey located at: https://www.surveymonkey.com/s.aspx?sm=loMM8qu18yFoKyi0rTUpQg_3d_3d Regards, Member Services American Registry for Internet Numbers (ARIN) From ge at linuxbox.org Tue Sep 16 10:52:24 2008 From: ge at linuxbox.org (Gadi Evron) Date: Tue, 16 Sep 2008 10:52:24 -0500 (CDT) Subject: community real-time BGP hijack notification service In-Reply-To: <20080912184350.F13D04500F@ptavv.es.net> References: <20080912184350.F13D04500F@ptavv.es.net> Message-ID: On Fri, 12 Sep 2008, Kevin Oberman wrote: > Looks interesting, but it only takes a fairly short list of ASNs for a > prefix. For our big CIDR blocks, we have WAY too many ASNs to enter them > all, so it's pretty useless for me. I need to be able to enter at very > least a dozen ASes and I suspect may folks have a LOT more then that. > We made many fixes over the last few days, as well as added a few more feeds. Any volunteers to give us more feeds? :) One of the fixes is that you can add many more ASs now, which should resolve your previous issues. Please let us know if you find any other problems or think of any suggestions, big and small. Gadi. > For now, I'll enter some shorter pieces from the block, but I'm most > concerned with the pieces that are not currently assigned, so are > available for hijack. I have added the larger, unassigned blocks. I'll > start adding assigned bits and pieces as well as unassigned pieces, but > being able to put all valid origin ASes in the list for the full blocks > would be a lot nicer. > -- > 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 woody at pch.net Tue Sep 16 11:10:56 2008 From: woody at pch.net (Bill Woodcock) Date: Tue, 16 Sep 2008 09:10:56 -0700 (PDT) Subject: Creating a visual Map of a network? In-Reply-To: <451268.84305.qm@web30807.mail.mud.yahoo.com> References: <451268.84305.qm@web30807.mail.mud.yahoo.com> Message-ID: On Tue, 16 Sep 2008 castellan2004-nsm at yahoo.com wrote: > This time I want to create a visual map of the LAN. Intermapper. http://dartware.com/network_monitoring_products/intermapper/index.html -Bill From jgreco at ns.sol.net Tue Sep 16 11:13:18 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 16 Sep 2008 11:13:18 -0500 (CDT) Subject: LoA (Letter of Authorization) for Prefix Filter Modification? In-Reply-To: from "Jon Lewis" at Sep 16, 2008 10:24:35 AM Message-ID: <200809161613.m8GGDICt084675@aurora.sol.net> > On Tue, 16 Sep 2008, Christian Koch wrote: > > I dont mind, i think it is another good step towards 'good filtering' > > but...i think the PITA part is > > downstream 'clueless' customers, who may need an explanation on prefix > > hijacking and the state > > of the internet today, and that these are all just combined efforts to > > minimize the risk of accepting allocations > > that don't belong to you. > > IMO, it's just an illusion of added security and is really just CYA for > the provider. When I fax TWTelecom an LOA that a customer faxed to me, > how does TWTelecom verify the authenticity of that LOA? I doubt they try. > I suspect it's just filed, and will only be pulled out if the > advertisement is challenged by some 3rd party. How do you verify the authenticity of anything? This is a common problem in the Real World, and is hardly limited to LoA's. How do you prove that what was on Pages 1 to (N-1) of an N page contract contained the words you think they said? I knew a guy, back in the early days, who habitually changed the SLA's in his contracts so that he could cancel a contract for virtually no reason at all ... the folly of mailing around contracts as .doc files in e-mail. But even failing that, it's pretty trivial to reprint a document, so where do you stop, do you use special paper, special ink, watermarking of documents, initial each page, all of the above, etc? Look at what people are willing to go through with paper checks to increase the chances of authenticity. Google Abagnale. The real world already has ways of dealing with fraud and forgery, and while the paper is certainly CYA for the provider, it does provide an actual trail back that can probably be followed to some party. To refer to it as an "illusion" is only vaguely true. It is an illusion in that it will not prevent all cases of hijacking. Of course. However, it is another step that makes it significantly more difficult for someone to just start announcing random bits of IP space. It's just like physical security, in many ways. Given a sufficiently determined attacker, any door can be broken. Wood door? May require only my boot. Steel door? Prybar. Bank vault? Explosives. Etc. The thing is, as you increase the level of protection, the ease of countermeasures typically decreases (I wear my boots almost 100% of the time, I may have a prybar nearby, but I am unlikely to be carrying explosives at any time.) So let's not trivialize improvements such as LoA's which reduce the ease of hijackings, eh. ... 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 babydr at baby-dragons.com Tue Sep 16 12:44:57 2008 From: babydr at baby-dragons.com (Mr. James W. Laferriere) Date: Tue, 16 Sep 2008 09:44:57 -0800 (AKDT) Subject: Creating a visual Map of a network? In-Reply-To: <451268.84305.qm@web30807.mail.mud.yahoo.com> References: <451268.84305.qm@web30807.mail.mud.yahoo.com> Message-ID: Hello Subba , On Tue, 16 Sep 2008, castellan2004-nsm at yahoo.com wrote: > I am being tasked to map a network. In the past I have used nmap to find the systems on the local LAN and remote LANs (same enterprise). > This time I want to create a visual map of the LAN. With cheops, I reasonably good results but cannot be documented for managers with certainty. What are some good tools now that will create visual maps of the networks? nmap can do this now , so I've been told . > What is the best way to map a network when ICMP echo has been turned off? > Thank you in advance for any help. > Subba Rao Hth, JimL -- +------------------------------------------------------------------+ | 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 vixie at isc.org Tue Sep 16 14:13:00 2008 From: vixie at isc.org (Paul Vixie) Date: Tue, 16 Sep 2008 19:13:00 +0000 Subject: Atrivo/Intercage: Now Only 1 Upstream In-Reply-To: <20080916124726.34FF67809@relayer.avian.org> (hobbit@avian.org's message of "Tue\, 16 Sep 2008 12\:47\:26 +0000 \(GMT\)") References: <20080916124726.34FF67809@relayer.avian.org> Message-ID: hobbit at avian.org (*Hobbit*) writes: > So in cases like this where the community appears to agree that there's > a consistently bad apple, what's preventing everyone from simply > nullrouting the netblocks in question and imposing the death penalty? http://www.spamhaus.org/drop/ seems to have atrivo on it. > Sorry if this seems naive, but if no legitimate purpose is shown it > seems like the obvious thing to do. Maybe they could still *send* > packets, but nothing would ever get back to them. legitimacy is in the mind of the beholder of course. -- Paul Vixie From Crist.Clark at globalstar.com Tue Sep 16 17:50:41 2008 From: Crist.Clark at globalstar.com (Crist Clark) Date: Tue, 16 Sep 2008 15:50:41 -0700 Subject: Procedure to Change Nameservers Message-ID: <48CFD5D1.8C45.0097.0@globalstar.com> This should be easy. But sometimes things that seem like they should be easy are not. I want to change the nameservers for a bunch of domains. Really, all I want to do is change the IP address, but it seems easier just to change both the name and IP to avoid any possibility of confusion. However, I am not "physically" moving the services. These are the same physical servers, just an additional IP address assigned to the appropriate interface. I want to do this the "right" way. Here's what I want to do. Am I doing anything wrong? (Am I being way too careful?) For the example, let's use the names, old-dns1, new-dns1, old-dns2, and new-dns2. I think you can guess what they mean. 1) Add new-dns1 and new-dns2 to the NS records for a domain. (Possible problem: I have NS records in my authorative DNS for the zone that are not in the hints at the gTLD server level. But that's not really a problem, right? They are not lame servers.) 2) Change the NAMESERVER entries at the registrar from old-dns1 to new-dn1 and old-dns2 to new-dns2. 3) Wait for the change to be reflected in the gTLD servers. 4) Wait for the TTL on the records to expire. 5) Wait a little bit longer just to be safe (maybe do some query logging to see who still is using the old ones). 6) Remove old-dns1 and old-dns2 NS records from the zone. 7) Wait for the TTL on the records to expire. 8) Wait a bit longer. 9) Turn off DNS services at old-dns1 and old-dns2 (i.e. take out the firewall rules that allow queries to those addresses). 10) ... 11) Profit. Not really too bad. At least we don't have to send in host record templates anymore. B?information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact postmaster at globalstar.com From markjr at easydns.com Tue Sep 16 18:39:41 2008 From: markjr at easydns.com (Mark Jeftovic) Date: Tue, 16 Sep 2008 19:39:41 -0400 Subject: Procedure to Change Nameservers In-Reply-To: <48CFD5D1.8C45.0097.0@globalstar.com> References: <48CFD5D1.8C45.0097.0@globalstar.com> Message-ID: <48D043BD.90100@easydns.com> Crist Clark wrote: > This should be easy. But sometimes things that seem like they > should be easy are not. > > I want to change the nameservers for a bunch of domains. Really, > all I want to do is change the IP address, but it seems easier > just to change both the name and IP to avoid any possibility of > confusion. I would just edit the nameserver glue recs and enter the new IPs and add the new IPs to the zone. If the nameservers are .com, .net or .org the roots will pick up the new glue within a few minutes, after about 10 days the TTLs on your root glue will expire and you can remove the old IPs from your firewall rules. You change your root glue recs for your nameservers via your registrar for the parent domain. -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 mike at rockynet.com Tue Sep 16 18:53:11 2008 From: mike at rockynet.com (Mike Lewinski) Date: Tue, 16 Sep 2008 17:53:11 -0600 Subject: Procedure to Change Nameservers In-Reply-To: <48CFD5D1.8C45.0097.0@globalstar.com> References: <48CFD5D1.8C45.0097.0@globalstar.com> Message-ID: <48D046E7.90909@rockynet.com> Crist Clark wrote: > 9) Turn off DNS services at old-dns1 and old-dns2 (i.e. take out > the firewall rules that allow queries to those addresses). > > 10) ... 10 ) Use one of the various sanity checking sites to validate some subset of your hosted domain configurations. We used to like http://www.dnsstuff.com a lot, but they've gone commercial. It's still a great service and possibly worth the money (I bought a membership but will be comparing it with the other free offerings in the coming months before our renewal is up to see if there's really enough value add). Free sites that perform similar DNS configuration checks that I know of are: http://dnssy.com http://www.intodns.com Mike From jmaimon at ttec.com Tue Sep 16 20:15:49 2008 From: jmaimon at ttec.com (Joe Maimon) Date: Tue, 16 Sep 2008 21:15:49 -0400 Subject: Procedure to Change Nameservers In-Reply-To: <48CFD5D1.8C45.0097.0@globalstar.com> References: <48CFD5D1.8C45.0097.0@globalstar.com> Message-ID: <48D05A45.4070101@ttec.com> Crist Clark wrote: > This should be easy. But sometimes things that seem like they > should be easy are not. > > I want to change the nameservers for a bunch of domains. Really, > all I want to do is change the IP address, but it seems easier > just to change both the name and IP to avoid any possibility of > confusion. However, I am not "physically" moving the services. > These are the same physical servers, just an additional IP address > assigned to the appropriate interface. I want to do this the > "right" way. Use a /32 routed to a host loopback interface. No reason to tie this to the network ethernet topology. Route it here, route it there, route it through the load balancer, route it dynamically, route it here AND there. Everything critical should be done that way. So much easier. Make a clear distinction between the names in the NS and corresponding records and hostnames you use on the network. They should never correspond. That way you will never need/want to change them. Keep the old addresses queryable for at least as long as your TTL was before the change. Maybe twice that. What does it cost you? If you can do that, make the changes all at once or however suits your fancy, so long as what you put in works when you put it in. if you keep the glue rec names/A the same as the zones NS records, there will be less bogus-lint complaints from things like dnsstuff, but you dont actually have to, as long as both sets work equally well. From Skywing at valhallalegends.com Tue Sep 16 20:28:00 2008 From: Skywing at valhallalegends.com (Skywing) Date: Tue, 16 Sep 2008 20:28:00 -0500 Subject: LoA (Letter of Authorization) for Prefix Filter Modification? Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6BD9A9D727D@caralain.haven.nynaeve.net> It is only a good audit trail if the audit log can be trusted, though. Given how "secure" things like faxes are, well, that's a thing for another day, I suppose. Very few things out there in today's interconnected world really provide "hard" security, instead of security theatre/CYA/minor deterrants/"keeping honest people honest". That is not to say that these things have zero inherent value, at least in my mind, but they are not IMO to be confused with high security (as in military grade versus making a few clever [socially engineered] phone calls). Even so, much of the modern day business world relies on these things to some degree or another. - S -----Original Message----- From: Joe Greco Sent: Tuesday, September 16, 2008 11:15 To: Jon Lewis Cc: Rodriguez Mauricio ; nanog at nanog.org Subject: Re: LoA (Letter of Authorization) for Prefix Filter Modification? > On Tue, 16 Sep 2008, Christian Koch wrote: > > I dont mind, i think it is another good step towards 'good filtering' > > but...i think the PITA part is > > downstream 'clueless' customers, who may need an explanation on prefix > > hijacking and the state > > of the internet today, and that these are all just combined efforts to > > minimize the risk of accepting allocations > > that don't belong to you. > > IMO, it's just an illusion of added security and is really just CYA for > the provider. When I fax TWTelecom an LOA that a customer faxed to me, > how does TWTelecom verify the authenticity of that LOA? I doubt they try. > I suspect it's just filed, and will only be pulled out if the > advertisement is challenged by some 3rd party. How do you verify the authenticity of anything? This is a common problem in the Real World, and is hardly limited to LoA's. How do you prove that what was on Pages 1 to (N-1) of an N page contract contained the words you think they said? I knew a guy, back in the early days, who habitually changed the SLA's in his contracts so that he could cancel a contract for virtually no reason at all ... the folly of mailing around contracts as .doc files in e-mail. But even failing that, it's pretty trivial to reprint a document, so where do you stop, do you use special paper, special ink, watermarking of documents, initial each page, all of the above, etc? Look at what people are willing to go through with paper checks to increase the chances of authenticity. Google Abagnale. The real world already has ways of dealing with fraud and forgery, and while the paper is certainly CYA for the provider, it does provide an actual trail back that can probably be followed to some party. To refer to it as an "illusion" is only vaguely true. It is an illusion in that it will not prevent all cases of hijacking. Of course. However, it is another step that makes it significantly more difficult for someone to just start announcing random bits of IP space. It's just like physical security, in many ways. Given a sufficiently determined attacker, any door can be broken. Wood door? May require only my boot. Steel door? Prybar. Bank vault? Explosives. Etc. The thing is, as you increase the level of protection, the ease of countermeasures typically decreases (I wear my boots almost 100% of the time, I may have a prybar nearby, but I am unlikely to be carrying explosives at any time.) So let's not trivialize improvements such as LoA's which reduce the ease of hijackings, eh. ... 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 jgreco at ns.sol.net Tue Sep 16 21:05:34 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 16 Sep 2008 21:05:34 -0500 (CDT) Subject: LoA (Letter of Authorization) for Prefix Filter Modification? In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D6BD9A9D727D@caralain.haven.nynaeve.net> from "Skywing" at Sep 16, 2008 08:28:00 PM Message-ID: <200809170205.m8H25Y57008167@aurora.sol.net> > It is only a good audit trail if the audit log can be trusted, though. Given how "secure" things like faxes are, well, that's a thing for another day, I suppose. > > Very few things out there in today's interconnected world really provide "hard" security, instead of security theatre/CYA/minor deterrants/"keeping honest people honest". > > That is not to say that these things have zero inherent value, at least in my mind, but they are not IMO to be confused with high security (as in military grade versus making a few clever [socially engineered] phone calls). > > Even so, much of the modern day business world relies on these things to some degree or another. As I said, there are already ways to deal with these issues. Unfortunately, most of them are reactive in nature. Despite that fact, I would much prefer to see a LoA, which will have some significant deterrent value, rather than nothing at all. The "security" of faxes has very little to do with it. If twtelecom finds that Jon Lewis over at Atlantic.net is sending in LoA's that turn out to be fraudulent, it is very likely that the level of scrutiny for future LoA's will suddenly increase, maybe involving calls to ARIN, the contact information for the organization in question, etc., to try to further determine the authenticity. On the flip side, if Jon has sent in a hundred LoA's, and none have ever been questioned, the level of scrutiny is likely to be reasonably low. Risk assessment in this environment isn't *that* rough, and worrying about whether or not the trail can be audited/ authenticated, security of faxes, etc., may be excessively paranoid. We do not have an Internet that is designed with "hard" security in mind, so worrying about the easily attacked portions is certainly worthwhile, but let's be thoughtful, rather than obsessive, about 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 Valdis.Kletnieks at vt.edu Tue Sep 16 21:21:56 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 16 Sep 2008 22:21:56 -0400 Subject: Atrivo/Intercage: Now Only 1 Upstream In-Reply-To: Your message of "Tue, 16 Sep 2008 12:47:26 -0000." <20080916124726.34FF67809@relayer.avian.org> References: <20080916124726.34FF67809@relayer.avian.org> Message-ID: <22966.1221618116@turing-police.cc.vt.edu> On Tue, 16 Sep 2008 12:47:26 -0000, *Hobbit* said: > So in cases like this where the community appears to agree that there's > a consistently bad apple, what's preventing everyone from simply "what's preventing everyone"? Geez Hobbit, I *know* you've been around long enough to know better than that :) We can't get a clear majority of providers to do BCP38, you expect them to apply a null route? And then to know to *remove* it once the problem withers up? ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From hobbit at avian.org Tue Sep 16 22:36:20 2008 From: hobbit at avian.org (*Hobbit*) Date: Wed, 17 Sep 2008 03:36:20 +0000 (GMT) Subject: Atrivo/Intercage: Now Only 1 Upstream Message-ID: <20080917033620.6EEF77808@relayer.avian.org> you expect them to apply a null route? Well, I *have* been talking somewhat idealistically here and there with this crop of questions, but frankly I thought in the 2 or 3 years I was ignoring the list that the NETWORK OPERATORS ostensibly in custody of the intertubes would have pulled things together a little better and grown enough of a pair to firmly state "this crap stops here and now" and make it happen. I do see pockets of good progress and research here and there and have gotten a lot of good feedback from people, but the big picture [as I watch my logs roll by] is pretty grim. Especially when the big players don't play at all. I've been around long enough to have a good idea of what *can* be done, but totally lost sight of any sensible reason why it *isn't*. Besides quarterly revenue, which is pretty short-sighted. Fortunately, I still have the luxury of being able to have my mailsystems tell cpe-*.rr.com and pool-*.verizon.net and c-24-*.comcast.net, along with large swaths of offshore IP space, to take a powder. Hundreds of times a day. But it's still their trash flying onto my tiny little lawn, and shouldn't be my job to sweep up. I mentally extend that picture to the millions of recipients who possibly aren't able to implement unusual and/or draconian filtering, and wonder how anybody ever gets any productive work done. _H* From mmc at internode.com.au Tue Sep 16 23:31:55 2008 From: mmc at internode.com.au (Matthew Moyle-Croft) Date: Wed, 17 Sep 2008 14:01:55 +0930 Subject: Atrivo/Intercage: Now Only 1 Upstream In-Reply-To: <20080916124726.34FF67809@relayer.avian.org> References: <20080916124726.34FF67809@relayer.avian.org> Message-ID: <68A8CC6C-2284-4C2B-96DE-45B162D89FE6@internode.com.au> On 16/09/2008, at 10:17 PM, *Hobbit* wrote: > So in cases like this where the community appears to agree that > there's > a consistently bad apple, what's preventing everyone from simply > nullrouting the netblocks in question and imposing the death penalty? Dunno - but something did occur to me this morning on the drive into work: Maybe there's another approach to this problem. Maybe, rather than having the antispam/virus vendors do non-real world lab tests we could get them all to donate some kit to whomever is the unlucky transit- provider du jour and see how well it works providing a nice clean feed and who's better at it? ;-) MMC -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks From r.bhatia at ipax.at Wed Sep 17 03:24:01 2008 From: r.bhatia at ipax.at (Raoul Bhatia [IPAX]) Date: Wed, 17 Sep 2008 10:24:01 +0200 Subject: LoA (Letter of Authorization) for Prefix Filter Modification? In-Reply-To: <200809161613.m8GGDICt084675@aurora.sol.net> References: <200809161613.m8GGDICt084675@aurora.sol.net> Message-ID: <48D0BEA1.2040603@ipax.at> Joe Greco wrote: > How do you verify the authenticity of anything? This is a common problem > in the Real World, and is hardly limited to LoA's. > > How do you prove that what was on Pages 1 to (N-1) of an N page contract > contained the words you think they said? I knew a guy, back in the early > days, who habitually changed the SLA's in his contracts so that he could > cancel a contract for virtually no reason at all ... the folly of mailing > around contracts as .doc files in e-mail. But even failing that, it's > pretty trivial to reprint a document, so where do you stop, do you use > special paper, special ink, watermarking of documents, initial each page, > all of the above, etc? what about using a digital signation of e.g. a pdf version of a scan? cheers, raoul -- ____________________________________________________________________ DI (FH) Raoul Bhatia M.Sc. email. r.bhatia at ipax.at Technischer Leiter IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at Barawitzkagasse 10/2/2/11 email. office at ipax.at 1190 Wien tel. +43 1 3670030 FN 277995t HG Wien fax. +43 1 3670030 15 ____________________________________________________________________ From list-nanog at pwns.ms Wed Sep 17 06:12:50 2008 From: list-nanog at pwns.ms (list-nanog at pwns.ms) Date: Wed, 17 Sep 2008 11:12:50 +0000 Subject: Procedure to Change Nameservers In-Reply-To: <48D046E7.90909@rockynet.com> References: <48CFD5D1.8C45.0097.0@globalstar.com> <48D046E7.90909@rockynet.com> Message-ID: <20080917111250.GA28166@pwns.ms> > Free sites that perform similar DNS configuration checks that I know of > are: > > http://dnssy.com > http://www.intodns.com Just to add to the list: http://squish.net/dnscheck/ From ops.lists at gmail.com Wed Sep 17 08:01:45 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 17 Sep 2008 15:01:45 +0200 Subject: Atrivo/Intercage: Now Only 1 Upstream In-Reply-To: <68A8CC6C-2284-4C2B-96DE-45B162D89FE6@internode.com.au> References: <20080916124726.34FF67809@relayer.avian.org> <68A8CC6C-2284-4C2B-96DE-45B162D89FE6@internode.com.au> Message-ID: Looks like PIE got themselves a /22 in spamhaus - http://www.spamhaus.org/sbl/sbl.lasso?query=SBL67906 _________quote__________ 206.223.144.0/22 is listed on the Spamhaus Block List (SBL) 17-Sep-2008 09:57 GMT | SR04 Pacific Internet Exchange LLC. NT Technology ; nttec.com http://cidr-report.org/cgi-bin/as-report?as=AS32335 Hosted/routed Scott Richter AND Alan Ralsky - now decided to pick up Intercage/Atrivo. Perhaps someone does not read the news? http://news.google.com/news?q=intercage http://www.spamhaus.org/news.lasso?article=636 We hope that's the case and this is not a knowing routing decision. On Wed, Sep 17, 2008 at 6:31 AM, Matthew Moyle-Croft wrote: > > On 16/09/2008, at 10:17 PM, *Hobbit* wrote: > >> So in cases like this where the community appears to agree that there's >> a consistently bad apple, what's preventing everyone from simply >> nullrouting the netblocks in question and imposing the death penalty? > > Dunno - but something did occur to me this morning on the drive into work: From lowen at pari.edu Wed Sep 17 09:25:21 2008 From: lowen at pari.edu (Lamar Owen) Date: Wed, 17 Sep 2008 10:25:21 -0400 Subject: Atrivo/Intercage: Now Only 1 Upstream In-Reply-To: <20080917033620.6EEF77808@relayer.avian.org> References: <20080917033620.6EEF77808@relayer.avian.org> Message-ID: <200809171025.21863.lowen@pari.edu> On Tuesday 16 September 2008 23:36:20 *Hobbit* wrote: > you expect them to apply a null route? > > Well, I *have* been talking somewhat idealistically here and > there with this crop of questions, but frankly I thought in the > 2 or 3 years I was ignoring the list that the NETWORK OPERATORS > ostensibly in custody of the intertubes would have pulled things > together a little better and grown enough of a pair to firmly > state "this crap stops here and now" and make it happen. :-) Speaking as an observer only, and not as someone who, other than at my own edge, could make a significant impact on the result. Seems to me getting that IP space on a bogon list could be enough to make a serious dent. From jgreco at ns.sol.net Wed Sep 17 11:22:20 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 17 Sep 2008 11:22:20 -0500 (CDT) Subject: LoA (Letter of Authorization) for Prefix Filter Modification? In-Reply-To: <48D0BEA1.2040603@ipax.at> from "Raoul Bhatia [IPAX]" at Sep 17, 2008 10:24:01 AM Message-ID: <200809171622.m8HGMKTI064265@aurora.sol.net> > Joe Greco wrote: > > How do you verify the authenticity of anything? This is a common problem > > in the Real World, and is hardly limited to LoA's. > > > > How do you prove that what was on Pages 1 to (N-1) of an N page contract > > contained the words you think they said? I knew a guy, back in the early > > days, who habitually changed the SLA's in his contracts so that he could > > cancel a contract for virtually no reason at all ... the folly of mailing > > around contracts as .doc files in e-mail. But even failing that, it's > > pretty trivial to reprint a document, so where do you stop, do you use > > special paper, special ink, watermarking of documents, initial each page, > > all of the above, etc? > > what about using a digital signation of e.g. a pdf version of a scan? Try putting that up next to an apparently legitimate but actually subtly modified paper contract with signatures, in a court of law, and feel free to inform us of which one the court finds more compelling. In an environment where there's an established history and standard procedures, they're typically going to prefer the familiar method. In our world, if we were to have some sort of crypto-based way to have a netblock owner sign something like that, yeah, that'd be great, and it would mean that the community would generally be able to manage the issue without having to resort to faxed-around LoA's, etc., but we don't have that infrastructure, or even a common/widespread LoA system. Sigh. I'm not arguing that some sort of technical/crypto infrastructure for authorizing the advertisement of space shouldn't be developed, and in fact I think it should. However, as an interim step, things like LoA's are much better than nothing at all, and worrying about the authenticity of an LoA is probably not worth the time and effort, given the way these things tend to work out. If there's cause for concern, those who are receiving the LoA's will ramp up the paranoia. ... 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 Skywing at valhallalegends.com Wed Sep 17 11:55:49 2008 From: Skywing at valhallalegends.com (Skywing) Date: Wed, 17 Sep 2008 11:55:49 -0500 Subject: Atrivo/Intercage: Now Only 1 Upstream Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D6BD9A9D7281@caralain.haven.nynaeve.net> Putting things in the automated bogon feeds (e.g. Team Cymru) that are not strictly bogons (unallocated addresses) is likely to very quickly erode trust in those services, if that is what you are suggesting. - S -----Original Message----- From: Lamar Owen Sent: Wednesday, September 17, 2008 09:26 To: nanog at nanog.org Subject: Re: Atrivo/Intercage: Now Only 1 Upstream On Tuesday 16 September 2008 23:36:20 *Hobbit* wrote: > you expect them to apply a null route? > > Well, I *have* been talking somewhat idealistically here and > there with this crop of questions, but frankly I thought in the > 2 or 3 years I was ignoring the list that the NETWORK OPERATORS > ostensibly in custody of the intertubes would have pulled things > together a little better and grown enough of a pair to firmly > state "this crap stops here and now" and make it happen. :-) Speaking as an observer only, and not as someone who, other than at my own edge, could make a significant impact on the result. Seems to me getting that IP space on a bogon list could be enough to make a serious dent. From ge at linuxbox.org Wed Sep 17 12:01:02 2008 From: ge at linuxbox.org (Gadi Evron) Date: Wed, 17 Sep 2008 12:01:02 -0500 (CDT) Subject: Atrivo/Intercage: Now Only 1 Upstream In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D6BD9A9D7281@caralain.haven.nynaeve.net> References: <982D8D05B6407A49AD506E6C3AC8E7D6BD9A9D7281@caralain.haven.nynaeve.net> Message-ID: On Wed, 17 Sep 2008, Skywing wrote: > Putting things in the automated bogon feeds (e.g. Team Cymru) that are not strictly bogons (unallocated addresses) is likely to very quickly erode trust in those services, if that is what you are suggesting. We all want a "really really bad stuff" BGP feed for anyone who wants it, but the Internet is not ready for that. Gadi. > - S > > -----Original Message----- > From: Lamar Owen > Sent: Wednesday, September 17, 2008 09:26 > To: nanog at nanog.org > Subject: Re: Atrivo/Intercage: Now Only 1 Upstream > > > On Tuesday 16 September 2008 23:36:20 *Hobbit* wrote: >> you expect them to apply a null route? >> >> Well, I *have* been talking somewhat idealistically here and >> there with this crop of questions, but frankly I thought in the >> 2 or 3 years I was ignoring the list that the NETWORK OPERATORS >> ostensibly in custody of the intertubes would have pulled things >> together a little better and grown enough of a pair to firmly >> state "this crap stops here and now" and make it happen. > > :-) Speaking as an observer only, and not as someone who, other than at my > own edge, could make a significant impact on the result. > > Seems to me getting that IP space on a bogon list could be enough to make a > serious dent. > > > From morrowc.lists at gmail.com Wed Sep 17 12:07:15 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 17 Sep 2008 13:07:15 -0400 Subject: Atrivo/Intercage: Now Only 1 Upstream In-Reply-To: References: <982D8D05B6407A49AD506E6C3AC8E7D6BD9A9D7281@caralain.haven.nynaeve.net> Message-ID: <75cb24520809171007v6282c6b4wd02f6ca1bffd2bf@mail.gmail.com> On Wed, Sep 17, 2008 at 1:01 PM, Gadi Evron wrote: > On Wed, 17 Sep 2008, Skywing wrote: >> >> Putting things in the automated bogon feeds (e.g. Team Cymru) that are not >> strictly bogons (unallocated addresses) is likely to very quickly erode >> trust in those services, if that is what you are suggesting. > > We all want a "really really bad stuff" BGP feed for anyone who wants it, > but the Internet is not ready for that. hrm, so actually there's a lot of supporting infrastructure that is necessary (or could be necessary) to implement something of that sort in any decent sized network. Provided you wanted to sinkhole the trafffic off somewhere to 'do the right thing' not just null0 the traffic, of course. There's the additional issue of allowing a third party to manage/traffic-engineer inside your network which might upset some operations folks. If you can build a list on your own in a reasonable fashion with supporting information and high confidence level that's one story, if this list comes from "someone else" whom you don't even have a billing-relationship with... it's hard to sell that when something bad happens. Certainly not everyone feels this way (see 'popularity' of the existing RBL/xbl lists) but in a larger network, or one that makes money ... How about providing some open-source intelligence in a centralized and machine-parsable fashion (perhaps with community input of intel even) which would allow better decsions to be made? -Chris From christian at broknrobot.com Wed Sep 17 12:28:21 2008 From: christian at broknrobot.com (Christian Koch) Date: Wed, 17 Sep 2008 13:28:21 -0400 Subject: Atrivo/Intercage: Now Only 1 Upstream In-Reply-To: <75cb24520809171007v6282c6b4wd02f6ca1bffd2bf@mail.gmail.com> References: <982D8D05B6407A49AD506E6C3AC8E7D6BD9A9D7281@caralain.haven.nynaeve.net> <75cb24520809171007v6282c6b4wd02f6ca1bffd2bf@mail.gmail.com> Message-ID: On Wed, Sep 17, 2008 at 1:07 PM, Christopher Morrow wrote: > On Wed, Sep 17, 2008 at 1:01 PM, Gadi Evron wrote: >> On Wed, 17 Sep 2008, Skywing wrote: >>> >>> Putting things in the automated bogon feeds (e.g. Team Cymru) that are not >>> strictly bogons (unallocated addresses) is likely to very quickly erode >>> trust in those services, if that is what you are suggesting. >> >> We all want a "really really bad stuff" BGP feed for anyone who wants it, >> but the Internet is not ready for that. > > hrm, so actually there's a lot of supporting infrastructure that is > necessary (or could be necessary) to implement something of that sort > in any decent sized network. Provided you wanted to sinkhole the > trafffic off somewhere to 'do the right thing' not just null0 the > traffic, of course. right on. > There's the additional issue of allowing a third party to > manage/traffic-engineer inside your network which might upset some > operations folks. If you can build a list on your own in a reasonable > fashion with supporting information and high confidence level that's > one story, if this list comes from "someone else" whom you don't even > have a billing-relationship with... it's hard to sell that when > something bad happens. and this is the exact reason i will not implement any of these auto-bgp feeds or drop lists in my network. now not only do i have internal operation folks fat fingers to worry about,but what if one of these third parties, as you pointed out, with no money changing hands or formal agreements,has fat fingers one day, and now adds a legitimate allocation to the feed/list? then what? > Certainly not everyone feels this way (see 'popularity' of the > existing RBL/xbl lists) but in a larger network, or one that makes > money ... > > How about providing some open-source intelligence in a centralized and > machine-parsable fashion (perhaps with community input of intel even) > which would allow better decsions to be made? > > -Chris > > Christian From davidu at everydns.net Wed Sep 17 12:32:01 2008 From: davidu at everydns.net (David Ulevitch) Date: Wed, 17 Sep 2008 10:32:01 -0700 Subject: Atrivo/Intercage: Now Only 1 Upstream In-Reply-To: <75cb24520809171007v6282c6b4wd02f6ca1bffd2bf@mail.gmail.com> References: <982D8D05B6407A49AD506E6C3AC8E7D6BD9A9D7281@caralain.haven.nynaeve.net> <75cb24520809171007v6282c6b4wd02f6ca1bffd2bf@mail.gmail.com> Message-ID: <48D13F11.6050600@everydns.net> Christopher Morrow wrote: > How about providing some open-source intelligence in a centralized and > machine-parsable fashion (perhaps with community input of intel even) > which would allow better decsions to be made? Reputation based on src_addr is /so/ 2005. ASN has a few more legs perhaps... but... All the growth in Internet-connected compute clouds (EC2, AppNexus, GoGrid, etc.) makes any system based around IP reputation decidedly less useful. At the end of the day, nobody is going to drop packets for amazon's IP space. -David From patrick at ianai.net Wed Sep 17 12:34:22 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 17 Sep 2008 13:34:22 -0400 Subject: Atrivo/Intercage: Now Only 1 Upstream In-Reply-To: <48D13F11.6050600@everydns.net> References: <982D8D05B6407A49AD506E6C3AC8E7D6BD9A9D7281@caralain.haven.nynaeve.net> <75cb24520809171007v6282c6b4wd02f6ca1bffd2bf@mail.gmail.com> <48D13F11.6050600@everydns.net> Message-ID: <675EC3C8-730F-475B-AB07-AEA3C352C669@ianai.net> On Sep 17, 2008, at 1:32 PM, David Ulevitch wrote: > Christopher Morrow wrote: > >> How about providing some open-source intelligence in a centralized >> and >> machine-parsable fashion (perhaps with community input of intel even) >> which would allow better decsions to be made? > > Reputation based on src_addr is /so/ 2005. ASN has a few more legs > perhaps... but... > > All the growth in Internet-connected compute clouds (EC2, AppNexus, > GoGrid, etc.) makes any system based around IP reputation decidedly > less useful. > > At the end of the day, nobody is going to drop packets for amazon's > IP space. I'm afraid reality disagrees with you - there already are networks doing it. Being big does not guarantee you ability to do Bad Things. -- TTFN, patrick From lowen at pari.edu Wed Sep 17 12:34:17 2008 From: lowen at pari.edu (Lamar Owen) Date: Wed, 17 Sep 2008 13:34:17 -0400 Subject: Atrivo/Intercage: Now Only 1 Upstream In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D6BD9A9D7281@caralain.haven.nynaeve.net> References: <982D8D05B6407A49AD506E6C3AC8E7D6BD9A9D7281@caralain.haven.nynaeve.net> Message-ID: <200809171334.17604.lowen@pari.edu> On Wednesday 17 September 2008 12:55:49 Skywing wrote: >> Lamar Owen Wrote: >> Seems to me getting that IP space on a bogon list could be enough to make a >> serious dent. > Putting things in the automated bogon feeds (e.g. Team Cymru) that are not > strictly bogons (unallocated addresses) is likely to very quickly erode > trust in those services, if that is what you are suggesting. Seems a similar topic has been here before... hrm... Yep, back around the first of August the subject came up of "Is it time to abandon bogon prefix filters?" in which thread you (among many others) were a participant. I don't have an archive link, sorry, since I used my personal archive of NANOG to find. Seems there are already trust, DoS, etc issues out there, in spades. But if someone wanted to do a 'badon' list and distribute in a similar fashion nothing is preventing folks for subscribing. The various antispam DNSBL's have multiple feeds of different kinds; some enterprising soul could do the same for routing. Will everyone do that? Of course not; some will choose to not, others will simply not care, and others will just ignore. Perhaps it could be called the wish-they-were-bogons list. Then a I-really-wish-they-were-bogons list for just the more severe block. The point made by Christopher Morrow is well taken: > There's the additional issue of allowing a third party to >manage/traffic-engineer inside your network which might upset some >operations folks. If you can build a list on your own in a reasonable >fashion with supporting information and high confidence level that's >one story, if this list comes from "someone else" whom you don't even >have a billing-relationship with... it's hard to sell that when >something bad happens. > >Certainly not everyone feels this way (see 'popularity' of the >existing RBL/xbl lists) but in a larger network, or one that makes >money ... Folks who use a DNSBL are already letting people in their network, in the e-mail sense at least (and some firewall interfaces to these lists). Those same people would likely not have a problem with a wish-they-were-bogons list. But, yeah, it's like chasing a weasel with an M134 with someone else aiming while you hold down the trigger. For infrastructure notes, see Team Cymru's description page at http://www.team-cymru.org/Services/Bogons/routeserver.html Seems easy enough to duplicate (of course, the devil is in the details, and nothing is as easy as it seems); and making the 'thing' 'do the right thing' is a matter of what routes are actually served by your route-servers. Perhaps a good use for that old Internet backbone router (or wannabe) that can no longer take a full BGP feed. From ge at linuxbox.org Wed Sep 17 12:40:02 2008 From: ge at linuxbox.org (Gadi Evron) Date: Wed, 17 Sep 2008 12:40:02 -0500 (CDT) Subject: Atrivo/Intercage: Now Only 1 Upstream In-Reply-To: <75cb24520809171007v6282c6b4wd02f6ca1bffd2bf@mail.gmail.com> References: <982D8D05B6407A49AD506E6C3AC8E7D6BD9A9D7281@caralain.haven.nynaeve.net> <75cb24520809171007v6282c6b4wd02f6ca1bffd2bf@mail.gmail.com> Message-ID: On Wed, 17 Sep 2008, Christopher Morrow wrote: > On Wed, Sep 17, 2008 at 1:01 PM, Gadi Evron wrote: >> On Wed, 17 Sep 2008, Skywing wrote: >>> >>> Putting things in the automated bogon feeds (e.g. Team Cymru) that are not >>> strictly bogons (unallocated addresses) is likely to very quickly erode >>> trust in those services, if that is what you are suggesting. >> >> We all want a "really really bad stuff" BGP feed for anyone who wants it, >> but the Internet is not ready for that. > > hrm, so actually there's a lot of supporting infrastructure that is > necessary (or could be necessary) to implement something of that sort > in any decent sized network. Provided you wanted to sinkhole the > trafffic off somewhere to 'do the right thing' not just null0 the > traffic, of course. > > There's the additional issue of allowing a third party to > manage/traffic-engineer inside your network which might upset some > operations folks. If you can build a list on your own in a reasonable > fashion with supporting information and high confidence level that's > one story, if this list comes from "someone else" whom you don't even > have a billing-relationship with... it's hard to sell that when > something bad happens. > > Certainly not everyone feels this way (see 'popularity' of the > existing RBL/xbl lists) but in a larger network, or one that makes > money ... > > How about providing some open-source intelligence in a centralized and > machine-parsable fashion (perhaps with community input of intel even) > which would allow better decsions to be made? Chris, that does not solve the one issue you did not mention: liability. Gadi. > -Chris > From lowen at pari.edu Wed Sep 17 13:03:43 2008 From: lowen at pari.edu (Lamar Owen) Date: Wed, 17 Sep 2008 14:03:43 -0400 Subject: Atrivo/Intercage: Now Only 1 Upstream In-Reply-To: <675EC3C8-730F-475B-AB07-AEA3C352C669@ianai.net> References: <982D8D05B6407A49AD506E6C3AC8E7D6BD9A9D7281@caralain.haven.nynaeve.net> Message-ID: <200809171403.43278.lowen@pari.edu> On Wednesday 17 September 2008 13:34:22 Patrick W. Gilmore wrote: > On Sep 17, 2008, at 1:32 PM, David Ulevitch wrote: > > At the end of the day, nobody is going to drop packets for amazon's > > IP space. > I'm afraid reality disagrees with you - there already are networks > doing it. Indeed. Google's e-mail servers get on the various DNSBL's frequently. > Being big does not guarantee you ability to do Bad Things. Might even provide incentive for the grid computing providers to keep tabs on what their uses are doing. Imagine that! Accountability, using the only 'stick' available. From sethm at rollernet.us Wed Sep 17 13:27:13 2008 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 17 Sep 2008 11:27:13 -0700 Subject: Atrivo/Intercage: Now Only 1 Upstream In-Reply-To: <200809171403.43278.lowen@pari.edu> References: <982D8D05B6407A49AD506E6C3AC8E7D6BD9A9D7281@caralain.haven.nynaeve.net> <200809171403.43278.lowen@pari.edu> Message-ID: <48D14C01.6060508@rollernet.us> Lamar Owen wrote: > On Wednesday 17 September 2008 13:34:22 Patrick W. Gilmore wrote: >> On Sep 17, 2008, at 1:32 PM, David Ulevitch wrote: >>> At the end of the day, nobody is going to drop packets for amazon's >>> IP space. > >> I'm afraid reality disagrees with you - there already are networks >> doing it. > > Indeed. Google's e-mail servers get on the various DNSBL's frequently. I occasionally get in to an argument with a customer who is trying to get mail from someone after a spam run came out of a google mail server and landed it on a DNSBL. The argument presented to me always boils down to "Google could never do anything wrong" or "Google is too big to do anything wrong" and I should immediately stop recommending any DNSBL that would dare to block Google. ~Seth From christopher.morrow at gmail.com Wed Sep 17 13:48:32 2008 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Wed, 17 Sep 2008 14:48:32 -0400 Subject: Atrivo/Intercage: Now Only 1 Upstream In-Reply-To: <200809171334.17604.lowen@pari.edu> References: <982D8D05B6407A49AD506E6C3AC8E7D6BD9A9D7281@caralain.haven.nynaeve.net> <200809171334.17604.lowen@pari.edu> Message-ID: <75cb24520809171148s1c1ae2a3ye71effacd4d60323@mail.gmail.com> On Wed, Sep 17, 2008 at 1:34 PM, Lamar Owen wrote: > The point made by Christopher Morrow is well taken: >> There's the additional issue of allowing a third party to >>manage/traffic-engineer inside your network which might upset some >>operations folks. If you can build a list on your own in a reasonable >>fashion with supporting information and high confidence level that's >>one story, if this list comes from "someone else" whom you don't even >>have a billing-relationship with... it's hard to sell that when >>something bad happens. >> >>Certainly not everyone feels this way (see 'popularity' of the >>existing RBL/xbl lists) but in a larger network, or one that makes >>money ... > > Folks who use a DNSBL are already letting people in their network, in the > e-mail sense at least (and some firewall interfaces to these lists). Those > same people would likely not have a problem with a wish-they-were-bogons > list. dropping email or port scans to known-vulnerable ports is very different from dropping all traffic from an ip/asn ... There have been cases of large content folks (MS comes to mind) being infected with badness, dropping that for a time is going to hurt more than dropping email from it only. > For infrastructure notes, see Team Cymru's description page at > http://www.team-cymru.org/Services/Bogons/routeserver.html > > Seems easy enough to duplicate (of course, the devil is in the details, and Sorry not just the route-server is necessary, if you want to do something aside from 'drop traffic on the floor'. Take, for instance the DNS Pinning attacks. If you have a large consumer base (or other base dependent up on recursive resolvers) discarding traffic towards the pinned resolvers is going to increase your costs... Prior to accepting the routing change if you setup some infrastructure to sinkhole the traffic and provide proper services out of that sinkhole you'd at least avoid that issue. where in your network can you sink a few gbps of traffic? regionally? locally? centrally? never? always? planning that out is necessary. -chris From Chris.Kleban at citrix.com Wed Sep 17 13:48:52 2008 From: Chris.Kleban at citrix.com (Chris Kleban) Date: Wed, 17 Sep 2008 11:48:52 -0700 Subject: Today's Point-2Point WAN Options In-Reply-To: <620fd17c0809151933k61a41be7t77e21c892584e9cd@mail.gmail.com> References: <3C230BCB8BFE31408F4E0B95C26A618CB12A52F5@sbapexch05> <620fd17c0809151933k61a41be7t77e21c892584e9cd@mail.gmail.com> Message-ID: <3C230BCB8BFE31408F4E0B95C26A618CB12A57CD@sbapexch05> See my comments inline below. The one question I have coming out of this is: If I want an economical sound solution that offers me high bandwidth and the ability to ensure end-to-end QoS, what is my best choice? So for it seems like a wavelength service meets those needs, with the negatives being that I need to deal with possible long outage times and manage things like fiber path redundancy myself. MPLS vpn services came in a close 2nd, but the price points I am seeing are outrageous. >>Chris Kleban wrote: >> Hello Nanog, >> >> I'm currently looking into what are the options for enabling inter-datacenter communication. >> >> Our current solution is to use ipsec/gre tunnels traversing over the Internet. The specific needs the new solution must meet are: >> >> - The ability to run end-to-end QOS. > >What are you trying to accomplish? > >Do you need to be able to pass DiffServ/DSCP tagging between sites? I'll be pushing different types of traffic (voice, video, http, nfs, etc) across the wan and want my different traffic classes queued appropriately from end to end. What I don't want is for there to be any layer 1,2,or3 hop that doesn't trust/pass/act on my dscp markings. >> - WaveLength Services (oc3-10gig): This service seems to be cheaper then traditional leased lines when comparing similar bandwidth. However, availability is limited to on-net buildings. This solution meets my needs. >Not a bad idea, but often overlooked when purchasing unprotected long-haul waves is that you can be down for days or weeks on end, depending on the severity of a given fiber cut. And protected waves cost significantly more because the carrier is provisioning twice the capacity -- sometimes in a configuration not as redundant as advertised. This is not for the faint of heart, and best left to ISPs who are buying from multiple vendors/cable systems and put in the effort to engineer suitable diversity. As an end-user, a switched service might afford you more economical route protection. There seems to be some more work required in managing things like fiber path redundancy yourself versus letting a carrier do it for you. >> - Dedicated bandwidth >> - Support 1gbps transfer rates >> - Enable communication between 3 locations >Okay. >> The options I have looked into so far are: >> >> - Layer 2 Ethernet (Virtual Private Line): This service seems to be offered by a lot of ISPs using various networking >techniques. The price point is attractive however packets are forwarded only at best effort across the ISP's network which means >the quality of the service will directly reflect the ISP's network performance. >How is this a problem? Is that concern that you never want an interface which is (physically, to routing protocols, ...) "up" but >latent and dropping packets like whoa, from an application or monitoring/management prospective? Jitter/loss can affect ef type traffic (voice) severely and I am trying to avoid this. >You raise a valid point about oversubscription. At the same time, this is often overhyped by marketing people, and dependent on how ghetto your pseudowire provider is and whether or not they know how to capacity-plan. >> - Traditional Leased Line (dsX/ocX): This service seems to be more expensive then wavelength services however meets my needs. >Quite. And it limits your router options significantly while driving up capex costs. Just say no! >> - MPLS based VPN solutions: Seems to be a good point to multipoint technology with QOS offerings. However, the price seems to be around the same as wavelength services for the amount of bandwidth we require. If the number of data centers we were looking to connect was larger then this option would be more attractive. This solution meets my needs. >(Assuming you're talking about l3vpn, as l2 can be grouped into your first example...) >It would probably help if you'd explain the "QOS" feature set of the offerings you're looking at. >This is a highly technically complex deployment; even at the largest telecoms, you can count on one hand the number of staff expert in its implementation and troubleshooting. It's also the most limiting in terms of specific routing protocols and prefix counts supported, the type of traffic you can pass, etc. The only benefit I can see to a l3vpn is in the enterprise with a lot of branch offices, where it simplifies end-site configurations and hub/spoke topology. Connecting your three datacenters, this is obviously not an issue. These are often the most expensive solutions too, given that their target customers have deep pockets. >> Based on my needs and what my options are I am leaning towards point to point wavelength services connecting my 3 locations in a loop like fashion. >> >> >> Are there any other options I should consider? >None come to mind. >> Are my descriptions of the today's possible solutions inaccurate? >More or less, though it would help if you'd explain more what you're trying to get out of the "QOS". Best Of Luck, and Drive Slow, Paul Wall From morrowc.lists at gmail.com Wed Sep 17 13:51:05 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 17 Sep 2008 14:51:05 -0400 Subject: Atrivo/Intercage: Now Only 1 Upstream In-Reply-To: References: <982D8D05B6407A49AD506E6C3AC8E7D6BD9A9D7281@caralain.haven.nynaeve.net> <75cb24520809171007v6282c6b4wd02f6ca1bffd2bf@mail.gmail.com> Message-ID: <75cb24520809171151t2db873dfpb1c3d1ce7a665506@mail.gmail.com> On Wed, Sep 17, 2008 at 1:40 PM, Gadi Evron wrote: > On Wed, 17 Sep 2008, Christopher Morrow wrote: >> How about providing some open-source intelligence in a centralized and >> machine-parsable fashion (perhaps with community input of intel even) >> which would allow better decsions to be made? > > Chris, that does not solve the one issue you did not mention: liability. if you can provide sourcing info and src tagging you could potentially limit some of the liability... but yes that's still an issue, the same issue as using any other existing BL though. 'oops jimbob at blplace.bl added www.amazon.com to the bl by mistake!' with some scoring system to set the reputation and associated query logic to pull out things over/under/around a threshold at least the users have some flexibility... if it's open sourced (how to make the list/content) then you can do that for yourself and the liability is all yours :) -Chris From morrowc.lists at gmail.com Wed Sep 17 13:41:23 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 17 Sep 2008 14:41:23 -0400 Subject: Atrivo/Intercage: Now Only 1 Upstream In-Reply-To: <48D13F11.6050600@everydns.net> References: <982D8D05B6407A49AD506E6C3AC8E7D6BD9A9D7281@caralain.haven.nynaeve.net> <75cb24520809171007v6282c6b4wd02f6ca1bffd2bf@mail.gmail.com> <48D13F11.6050600@everydns.net> Message-ID: <75cb24520809171141w1a7f1cc8jef1a48cf5ee202a7@mail.gmail.com> On Wed, Sep 17, 2008 at 1:32 PM, David Ulevitch wrote: > Christopher Morrow wrote: > >> How about providing some open-source intelligence in a centralized and >> machine-parsable fashion (perhaps with community input of intel even) >> which would allow better decsions to be made? > > Reputation based on src_addr is /so/ 2005. ASN has a few more legs > perhaps... but... > > All the growth in Internet-connected compute clouds (EC2, AppNexus, GoGrid, > etc.) makes any system based around IP reputation decidedly less useful. > there is more than 'srcip' you can use to judge reputation on... if you have something 'not a router' you can even implement other options... Adding things like ttl's to the entries, sliding the reputation on that as well. It's not just 'src ip'. ASN is a really big hammer.... > At the end of the day, nobody is going to drop packets for amazon's IP > space. > nope, but amazon can/may-be-able-to do some protections on their side, or individuals could choose to block bits/pieces of amazon, and they have already. > -David > > From davids at webmaster.com Wed Sep 17 14:25:51 2008 From: davids at webmaster.com (David Schwartz) Date: Wed, 17 Sep 2008 12:25:51 -0700 Subject: Atrivo/Intercage: Now Only 1 Upstream In-Reply-To: <48D14C01.6060508@rollernet.us> Message-ID: > I occasionally get in to an argument with a customer who is trying to > get mail from someone after a spam run came out of a google mail server > and landed it on a DNSBL. The argument presented to me always boils down > to "Google could never do anything wrong" or "Google is too big to do > anything wrong" and I should immediately stop recommending any DNSBL > that would dare to block Google. > > ~Seth A more rational version of this argument would be that blocking Google's mail servers will obviously have large amounts of collatarel damage. Any DNSBL that blocks Google's mail servers, other than perhaps in sufficiently serious situations to justify this level of collatarel damage, shouldn't be recommended. You should provide a way for customers to opt out of your blacklists. Many people are perfectly happy to run their own spam filtering software and retain the capability to skim (or analyze) their spam. If you provide a way for your customer to do this, point them to it. If not, that is a failing on your part. (Though of course it's always possible you have cost/benefit arguments that justify not providing that service.) Some people would really like email to be as reliable as possible, even if that means they have to wade through a lot of spam. At least this gives them ability to whitelist sources that are important to them personally. David Schwartz From davidu at everydns.net Wed Sep 17 15:07:50 2008 From: davidu at everydns.net (David Ulevitch) Date: Wed, 17 Sep 2008 13:07:50 -0700 Subject: Atrivo/Intercage: Now Only 1 Upstream In-Reply-To: <675EC3C8-730F-475B-AB07-AEA3C352C669@ianai.net> References: <982D8D05B6407A49AD506E6C3AC8E7D6BD9A9D7281@caralain.haven.nynaeve.net> <75cb24520809171007v6282c6b4wd02f6ca1bffd2bf@mail.gmail.com> <48D13F11.6050600@everydns.net> <675EC3C8-730F-475B-AB07-AEA3C352C669@ianai.net> Message-ID: <48D16396.8040309@everydns.net> Patrick W. Gilmore wrote: > On Sep 17, 2008, at 1:32 PM, David Ulevitch wrote: >> At the end of the day, nobody is going to drop packets for amazon's IP >> space. > > I'm afraid reality disagrees with you - there already are networks doing > it. > > Being big does not guarantee you ability to do Bad Things. > I didn't imply that it did. But the ability to block without causing significant collateral damage becomes more and more difficult as IPs become less tied to the organization using them. That said, you're right that people are doing it now. Consensus from friends running their apps on EC2 is that you can't expect to be able to send any email from EC2 and hope for a high deliverability rate. From sethm at rollernet.us Wed Sep 17 15:24:53 2008 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 17 Sep 2008 13:24:53 -0700 Subject: Atrivo/Intercage: Now Only 1 Upstream In-Reply-To: References: Message-ID: <48D16795.2010602@rollernet.us> David Schwartz wrote: >> I occasionally get in to an argument with a customer who is trying to >> get mail from someone after a spam run came out of a google mail server >> and landed it on a DNSBL. The argument presented to me always boils down >> to "Google could never do anything wrong" or "Google is too big to do >> anything wrong" and I should immediately stop recommending any DNSBL >> that would dare to block Google. >> >> ~Seth > > A more rational version of this argument would be that blocking Google's > mail servers will obviously have large amounts of collatarel damage. Any > DNSBL that blocks Google's mail servers, other than perhaps in sufficiently > serious situations to justify this level of collatarel damage, shouldn't be > recommended. > > You should provide a way for customers to opt out of your blacklists. Many > people are perfectly happy to run their own spam filtering software and > retain the capability to skim (or analyze) their spam. > > If you provide a way for your customer to do this, point them to it. If not, > that is a failing on your part. (Though of course it's always possible you > have cost/benefit arguments that justify not providing that service.) > > Some people would really like email to be as reliable as possible, even if > that means they have to wade through a lot of spam. At least this gives them > ability to whitelist sources that are important to them personally. > Oh, they can. They have full control of everything hardcore filtering to nothing at all and anything in between. They could prune out the DNSBL they didn't like, turn off DNSBL completely, whitelist the source CIDR range (which I gave them), whitelist the sender's address/domain, etc. There was 15 different ways they could have fixed it, but didn't want to. I can't really say why. All they would say is "it's Google." ~Seth From LarrySheldon at cox.net Wed Sep 17 15:53:35 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Wed, 17 Sep 2008 15:53:35 -0500 Subject: Atrivo/Intercage: Now Only 1 Upstream In-Reply-To: References: Message-ID: <48D16E4F.6090808@cox.net> > Some people would really like email to be as reliable as possible, even if > that means they have to wade through a lot of spam. By what twisted logic can a system where desired email is found when " they have to wade through a lot of spam"? Have you ever inadvertently deleted a desired item in the middle of a delete-yes-delete-yes-delete-yes-delete-yes-delete-yes-delete-yes sequence that went on for "a lot of spam"? How many times? Did you recover all of the desired items? How do you know that? To me a reliable system is one that delivers what I want and only what I want every time. And having to pick the pepper out of the flysh*t is not my idea of "reliable". From peter.serwe at gmail.com Wed Sep 17 16:14:07 2008 From: peter.serwe at gmail.com (Peter Serwe) Date: Wed, 17 Sep 2008 14:14:07 -0700 Subject: Any group(s) discounts to NANOG in LA? Message-ID: I'm so close to it, not attending is not really an option.. Peter -- ???? From pauldotwall at gmail.com Wed Sep 17 16:26:34 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Wed, 17 Sep 2008 17:26:34 -0400 Subject: Atrivo Update Message-ID: <620fd17c0809171426p6444fcf0x9a5d0a43307511d4@mail.gmail.com> I've been in touch with all of the upstream transit providers currently routing Atrivo/Intercage netblocks. Without naming any names, they are all aware, and working on getting them pulled in accordiance with their AUPs. Hats off particularly to NTT and AboveNet for going the extra mile here. (Unfortuantely, I understand sales and contractual pushback can sometimes put a damper on these things.) Gas is still expensive, so Drive Slow, Paul Wall From lowen at pari.edu Wed Sep 17 16:27:19 2008 From: lowen at pari.edu (Lamar Owen) Date: Wed, 17 Sep 2008 17:27:19 -0400 Subject: Atrivo/Intercage: Now Only 1 Upstream In-Reply-To: <48D16E4F.6090808@cox.net> References: Message-ID: <200809171727.20166.lowen@pari.edu> On Wednesday 17 September 2008 16:53:35 Laurence F. Sheldon, Jr. wrote: > > Some people would really like email to be as reliable as possible, even > > if that means they have to wade through a lot of spam. > > By what twisted logic can a system where desired email is found when " > they have to wade through a lot of spam"? When our spam rate here is 90% (27,000 or more spam per week for 3,000 good messages) 'wading through spam' translates to 'finding real messages is like finding a needle in a pr0n haystack'. It's amazing how many false positives and annoyances I get with greylisting, though. From scg at gibbard.org Wed Sep 17 18:39:09 2008 From: scg at gibbard.org (Steve Gibbard) Date: Wed, 17 Sep 2008 16:39:09 -0700 (PDT) Subject: Atrivo/Intercage: Now Only 1 Upstream In-Reply-To: <48D13F11.6050600@everydns.net> References: <982D8D05B6407A49AD506E6C3AC8E7D6BD9A9D7281@caralain.haven.nynaeve.net> <75cb24520809171007v6282c6b4wd02f6ca1bffd2bf@mail.gmail.com> <48D13F11.6050600@everydns.net> Message-ID: <20080917162729.Q86994@sprockets.gibbard.org> On Wed, 17 Sep 2008, David Ulevitch wrote: > Reputation based on src_addr is /so/ 2005. ASN has a few more legs > perhaps... but... > > All the growth in Internet-connected compute clouds (EC2, AppNexus, GoGrid, > etc.) makes any system based around IP reputation decidedly less useful. > > At the end of the day, nobody is going to drop packets for amazon's IP space. While I can't speak for the others on your list, we have been putting a fair amount of thought into abuse detection and mitigation at GoGrid. We are well aware of the problems we would have if our address space were to end up with a bad reputation. If stuff does get through that shouldn't, please contact abuse at gogrid.com and we'll take care of it. -Steve From saulbangmoll at gmail.com Wed Sep 17 19:02:44 2008 From: saulbangmoll at gmail.com (Saul Moll) Date: Wed, 17 Sep 2008 17:02:44 -0700 Subject: Any group(s) discounts to NANOG in LA? In-Reply-To: References: Message-ID: <17ed5c700809171702o744eb34dtae848e97959f3dbd@mail.gmail.com> 2008/9/17 Peter Serwe > I'm so close to it, not attending is not really an option.. Peter, Your message was a little cryptic, but I assume you are inquiring about the accomodations. If you go to www.nanog.org, and then click on the link entitled 'Hotel Information,' (just look for the bright red text) it leads you to: http://www.nanog.org/meetings/nanog44/hotel.php Where you can find all sorts of information. But book now, the rate expires tomorrow! Saul P.S. There are always options in life, don't give up hope. From peter.serwe at gmail.com Wed Sep 17 19:18:56 2008 From: peter.serwe at gmail.com (Peter Serwe) Date: Wed, 17 Sep 2008 17:18:56 -0700 Subject: Any group(s) discounts to NANOG in LA? In-Reply-To: <17ed5c700809171702o744eb34dtae848e97959f3dbd@mail.gmail.com> References: <17ed5c700809171702o744eb34dtae848e97959f3dbd@mail.gmail.com> Message-ID: Actually, I was inquiring about the registration fee. I live close enough and my gear is a few buildings down from the location. Peter On Wed, Sep 17, 2008 at 5:02 PM, Saul Moll wrote: > 2008/9/17 Peter Serwe >> I'm so close to it, not attending is not really an option.. > > Peter, > > Your message was a little cryptic, but I assume you are > inquiring about the accomodations. > > If you go to www.nanog.org, and then click on the link entitled > 'Hotel Information,' (just look for the bright red text) it leads you to: > > http://www.nanog.org/meetings/nanog44/hotel.php > > Where you can find all sorts of information. But book now, the > rate expires tomorrow! > > Saul > > P.S. There are always options in life, don't give up hope. > -- ???? From bburke at merit.edu Wed Sep 17 19:28:09 2008 From: bburke at merit.edu (Betty Burke) Date: Wed, 17 Sep 2008 20:28:09 -0400 (EDT) Subject: [NANOG-announce] NANOG44 Updates In-Reply-To: <316747249.997341221697614952.JavaMail.root@crono> Message-ID: <1689305955.997361221697689815.JavaMail.root@crono> Hello Everyone:> As Philip Smith indicated... a few more update messages to the community will be coming, and here is one of them. First, Merit would like to draw your attention to the Hotel Reservation link http://nanog.org/meetings/nanog44/hotel.php An IMPORTANT NOTE to be aware of is, the Hotel room block rate EXPIRES on FRIDAY, Sept. 19! Merit has reserved rooms for the community, so please do reserve your room before the deadline. Just an easy click away. So now that you have reserved your room, you should check out the updated NANOG44 meeting agenda. http://nanog.org/meetings/nanog44/agenda.php Highlights include: Updated presentations and content information, along with meeting room assignments. Soon, Merit will also highlight which presentations will be broadcast and which will be encoded for future reference. For the first time while at NANOG, Merit will have a room assigned to view the Fall 2008 Internet2 Member Meeting netcast. There are evening events on Sunday, Monday and Tuesday!! And we have a very exciting joint session with ARIN on Wednesday morning. Lastly, the NANOG-Attendee at nanog.org email list will help you keep in touch with each other. It will also be the distribution method for sharing additional site and meeting specific information. Make sure if you are attending, you are subscribed!! Again, on behalf of Merit Network, the NANOG SC and PC, we encourage you to attend this exciting meeting. We are confident this is one meeting you will not want to miss !! Hope to see many of you in LA and as always, if you have any questions or concerns regarding the meeting venue or registration, please send a note to NANOG-Support at nanog.org. Sincerely, Betty Burke Merit/NANOG Project Manager Merit Network Inc. Merit/NANOG Project Manager _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From tomb at byrneit.net Wed Sep 17 21:17:36 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Wed, 17 Sep 2008 19:17:36 -0700 Subject: Atrivo/Intercage: Now Only 1 Upstream In-Reply-To: <48D14C01.6060508@rollernet.us> References: <982D8D05B6407A49AD506E6C3AC8E7D6BD9A9D7281@caralain.haven.nynaeve.net><200809171403.43278.lowen@pari.edu> <48D14C01.6060508@rollernet.us> Message-ID: <70D072392E56884193E3D2DE09C097A9F5A9@pascal.zaphodb.org> Welcome the Internet version of "Too big to fail". I like the corollary: If it's too big to fail, it's too big, and needs to be broken up. Otherwise, we get an oligarchy, > -----Original Message----- > From: Seth Mattinen [mailto:sethm at rollernet.us] > Sent: Wednesday, September 17, 2008 11:27 AM > To: nanog at nanog.org > Subject: Re: Atrivo/Intercage: Now Only 1 Upstream > > Lamar Owen wrote: > > On Wednesday 17 September 2008 13:34:22 Patrick W. Gilmore wrote: > >> On Sep 17, 2008, at 1:32 PM, David Ulevitch wrote: > >>> At the end of the day, nobody is going to drop packets > for amazon's > >>> IP space. > > > >> I'm afraid reality disagrees with you - there already are networks > >> doing it. > > > > Indeed. Google's e-mail servers get on the various DNSBL's > frequently. > > > I occasionally get in to an argument with a customer who is > trying to get mail from someone after a spam run came out of > a google mail server and landed it on a DNSBL. The argument > presented to me always boils down to "Google could never do > anything wrong" or "Google is too big to do anything wrong" > and I should immediately stop recommending any DNSBL that > would dare to block Google. > > ~Seth > > From cayle.spandon at gmail.com Wed Sep 17 21:32:29 2008 From: cayle.spandon at gmail.com (Cayle Spandon) Date: Wed, 17 Sep 2008 22:32:29 -0400 Subject: Mechanisms for a multi-homed host to pick the best router Message-ID: <71c13900809171932m477b5d51jf0e0f9883546e3c3@mail.gmail.com> (My apologies, in advance, for the fact that this question is very long winded.) I have a server which is multi-homed to N routers as shown below: +---+ R1---| | | | R2---| | ... | S | | | Rn---| | +---+ This server is a host; it is not a router in the sense that it will never forward any packets (but it might run routing protocols as discussed below). Also, for the sake of simplicity in this discussion, let's say this server only receives inbound TCP connections; it never initiates outbound TCP connections. Finally, this server has a loopback address L. All traffic destined to the server uses address L as the destination address. All N routers have a static route to L and inject that route into their routing protocol (possibly as part of an aggregate). Now, imagine the server receives an inbound connection from another host whose address is A. Thus, the TCP SYN packet which S receives has source address A and destination address L. When the server sends TCP traffic for that same connection back to host A, it needs to pick one of the N routers, in other words, it needs to pick an outbound interface from its N interfaces. Traditionally, this is done by doing a best-match lookup for address A in the forwarding table of the server. One could install a ECMP default route which points to all N routers. In this case, the downstream router would essentially be picked at random (for each connection, assuming 5-tuple hashing). The problem is that some routers are "better" than other routers in the sense that they are closer to the final destination address A. (For example, each router could be connected to a different ISP.) One way for the server to pick the "optimal" downstream router, is to run "stub BGP" between the server and each of the routers. By "stub BGP" I mean that the server uses the BGP session only to learn routes. It advertises its own loopback L, but it never advertises any other routes, and it never propagates and routes from one BGP session to another BGP session. The server would have N BGP sessions and learn the full default-free BGP route table over each of those sessions. In other words, the server would end up with approximately N x 250,000 routes in its RIB and 250,000 routes in its FIB. While this approach would certainly allow the server to pick the optimal downstream router in all cases, I would prefer not to run routing protocols on this server for a number of reasons: - I don't want to the spend memory and CPU on such large RIBs and FIBs. - I'm afraid that other routers will attempt to forward traffic through the server (due to accidental misconfigurations) once it starts participating in the routing protocols. - Since there might be many of these servers (many more than the number of routers) I might end up stretching the routers beyond their scaling limits (number of BGP sessions, link state database size, etc.) and destabilizing the network. - I know there are good open source implementation of routing protocols, but still, I'm nervous that any instability or bugs on the servers could end up screwing up the routers (e.g. persistent BGP flaps). - One possible variation is that the server is a client of some route-reflectors which are not in the forwarding path (i.e. next-hop-self is not enabled). In that case, I might end up needing to do BGP next-hop resolution for a very large number of BGP next-hops. This, in turn, implies that the server might need to also run OSPF in a very large flat area 0. For all these reasons, I don't want to run BGP on the server. Someone suggested an idea to me which seems almost to simple to work, but I cannot find any good reason why it would not work. The idea is "the server simply sends all outbound traffic for the TCP connection out over the same interface over which the most recent TCP traffic for that connection was received". So, for example, if the server receives the SYN from router R3, it would send the SYN ACK and all subsequent packets for the TCP connection over that same interface R3. If the inbound packets for that same TCP connection start arriving from a different router (e.g. because of link failure), say R4, then the server also switches the outbound packets to that same router R4. I am aware that routing is not always symmetrical. In other words, I am aware that the best route from A to Z might be A->B->C->Z while the best route from Z to A might be Z->D->A. However, since the IP routing tables form an inverted tree, it seems to me that in realistic scenarios the traffic should still arrive at A (maybe over a non-optimal path in rare cases) if Z sends the reverse traffic to C instead of D. It seems unlikely (impossible?) that this would cause a routing loop. I can think of the following problems with this approach: (Problem 1) It only works for inbound TCP connections and not for outbound TCP connections. For outbound TCP connections we would not know which router to send the first SYN packet to. (Problem 2) If there is a topology change after the TCP connection has been established, the traffic might follow a sub-optimal path. In extreme cases, after a topology change the TCP connection might be lost despite the availability of an alternative feasible path. For example, if server S is using router R1 to reach host A, and router R1 can no longer reach host A, and host A is not sending *any* traffic to server S, then server S is not going to find out about the topology change (since S doesn't receive any traffic from A), and the connection is going to be dropped (because S's retransmission will never reach A). Many application layer protocols have a keep-alive message at the application layer; in that case the problem would not occur because host A would always be sending some traffic to server S which would allow S to discover the topology change by virtue of A's traffic arriving from a different router. My question for the NANOG community are these: (Question 1) Can you think of any additional problems with this approach? Specifically, I am interested in persistent failures in the absence of topology changes. (Question 2) Is there another mechanism for the server (a multi-homed host) to pick a best router, short of running stub BGP? Are there any standards for this? (Question 3) If the answer to question 2 is "no", is there any interest in standardizing a protocol for a multi-homed host to pick a best next-hop router? One could think of this is a host-to-router routing protocol. One might call the existing routing protocols router-to-router protocols (because I think we are abusing them by running them on hosts). This is somewhat analogous to the multicast routing world where we use different protocols for router-to-router multicast (PIM) versus host-to-router (IGMP). -- Cayle From LarrySheldon at cox.net Wed Sep 17 21:42:15 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Wed, 17 Sep 2008 21:42:15 -0500 Subject: Mechanisms for a multi-homed host to pick the best router In-Reply-To: <71c13900809171932m477b5d51jf0e0f9883546e3c3@mail.gmail.com> References: <71c13900809171932m477b5d51jf0e0f9883546e3c3@mail.gmail.com> Message-ID: <48D1C007.9060005@cox.net> Cayle Spandon wrote: > I have a server which is multi-homed to N routers as shown below: > > +---+ > R1---| | > | | > R2---| | > ... | S | > | | > Rn---| | > +---+ > > This server is a host; it is not a router in the sense that it will never > forward any packets (but it might run routing protocols as discussed below). This is going to be the stupid question of the day, but unless you have a route policy (in which case, what was the question again?) why would you not sent the reply out the same spigot you go the request on? From vixie at isc.org Wed Sep 17 22:49:10 2008 From: vixie at isc.org (Paul Vixie) Date: Thu, 18 Sep 2008 03:49:10 +0000 Subject: Mechanisms for a multi-homed host to pick the best router In-Reply-To: <71c13900809171932m477b5d51jf0e0f9883546e3c3@mail.gmail.com> (Cayle Spandon's message of "Wed\, 17 Sep 2008 22\:32\:29 -0400") References: <71c13900809171932m477b5d51jf0e0f9883546e3c3@mail.gmail.com> Message-ID: cayle.spandon at gmail.com ("Cayle Spandon") writes: > (My apologies, in advance, for the fact that this question is very long > winded.) np. > I have a server which is multi-homed to N routers as shown below: > > +---+ > R1---| | > | | > R2---| | > ... | S | > | | > Rn---| | > +---+ > > This server is a host; it is not a router in the sense that it will never > forward any packets (but it might run routing protocols as discussed below). > > Also, for the sake of simplicity in this discussion, let's say this server > only receives inbound TCP connections; it never initiates outbound TCP > connections. > > Finally, this server has a loopback address L. All traffic destined to the > server uses address L as the destination address. All N routers have a > static route to L and inject that route into their routing protocol > (possibly as part of an aggregate). > > Now, imagine the server receives an inbound connection from another host > whose address is A. Thus, the TCP SYN packet which S receives has source > address A and destination address L. ... > For all these reasons, I don't want to run BGP on the server. "too many moving parts." > Someone suggested an idea to me which seems almost to simple to work, but I > cannot find any good reason why it would not work. > > The idea is "the server simply sends all outbound traffic for the TCP > connection out over the same interface over which the most recent TCP > traffic for that connection was received". > > So, for example, if the server receives the SYN from router R3, it would > send the SYN ACK and all subsequent packets for the TCP connection over that > same interface R3. > ... right idea. works great. see the following: http://www.academ.com/nanog/feb1997/multihoming.html http://www.irbs.net/internet/nanog/9706/0232.html http://gatekeeper.dec.com/pub/misc/vixie/ifdefault/ > ... > I can think of the following problems with this approach: > > (Problem 1) It only works for inbound TCP connections and not for outbound > TCP connections. For outbound TCP connections we would not know which router > to send the first SYN packet to. you said above you only needed inbound. for outbound and udp: round robin. > ... > My question for the NANOG community are these: > > (Question 1) Can you think of any additional problems with this approach? > Specifically, I am interested in persistent failures in the absence of > topology changes. topology change frequency is in a different order of magnitude than the usual tcp session startup frequency, so unless you've got long running tcp sessions which won't restart on a connection reset, you've got no problem, and if you do have that kind of tcp session, you've already got problems. > (Question 2) Is there another mechanism for the server (a multi-homed host) > to pick a best router, short of running stub BGP? Are there any standards > for this? there are a bazillion patented and/or ubersecret ways to do this. noone has ever demonstrated anything that works better than an undercommitted network with undercommitted connections to other undercommitted first-hop networks. > (Question 3) If the answer to question 2 is "no", is there any interest > in standardizing a protocol for a multi-homed host to pick a best > next-hop router? One could think of this is a host-to-router routing > protocol. One might call the existing routing protocols router-to-router > protocols (because I think we are abusing them by running them on > hosts). This is somewhat analogous to the multicast routing world where > we use different protocols for router-to-router multicast (PIM) versus > host-to-router (IGMP). sadly, this has been tried, but it always runs into least-cost routing issues whereby not only the predicted connection quality but also contract details like whether this is over or under the per-period minima and how many quatloos per kilosegment it will cost all have to get exchanged at high speed with low latency and good accuracy. been there, did that, got no useful t-shirt even. -- Paul Vixie From ops.lists at gmail.com Thu Sep 18 02:37:53 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 18 Sep 2008 09:37:53 +0200 Subject: Atrivo/Intercage: Now Only 1 Upstream In-Reply-To: References: <982D8D05B6407A49AD506E6C3AC8E7D6BD9A9D7281@caralain.haven.nynaeve.net> Message-ID: It exists but not in bgp form - http://www.spamhaus.org/drop/ Dont Route Or Peer srs On Wed, Sep 17, 2008 at 7:01 PM, Gadi Evron wrote: > On Wed, 17 Sep 2008, Skywing wrote: >> >> Putting things in the automated bogon feeds (e.g. Team Cymru) that are not >> strictly bogons (unallocated addresses) is likely to very quickly erode >> trust in those services, if that is what you are suggesting. > > We all want a "really really bad stuff" BGP feed for anyone who wants it, > but the Internet is not ready for that. From andy at nosignal.org Thu Sep 18 03:44:25 2008 From: andy at nosignal.org (Andy Davidson) Date: Thu, 18 Sep 2008 09:44:25 +0100 Subject: Atrivo/Intercage: Now Only 1 Upstream In-Reply-To: <48D13F11.6050600@everydns.net> References: <982D8D05B6407A49AD506E6C3AC8E7D6BD9A9D7281@caralain.haven.nynaeve.net> <75cb24520809171007v6282c6b4wd02f6ca1bffd2bf@mail.gmail.com> <48D13F11.6050600@everydns.net> Message-ID: <2B6AA123-9315-4EC6-9AB1-70C1E4E5311C@nosignal.org> On 17 Sep 2008, at 18:32, David Ulevitch wrote: > At the end of the day, nobody is going to drop packets for amazon's > IP space. I have a customer that sells online, and is dropping stuff from ec2 today due to abuse. Andy From jrhett at netconsonance.com Thu Sep 18 04:45:16 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu, 18 Sep 2008 02:45:16 -0700 Subject: Procedure to Change Nameservers In-Reply-To: <48CFD5D1.8C45.0097.0@globalstar.com> References: <48CFD5D1.8C45.0097.0@globalstar.com> Message-ID: On Sep 16, 2008, at 3:50 PM, Crist Clark wrote: > I want to change the nameservers for a bunch of domains Then ask the question on a list related to DNS. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From joe at sumless.net Thu Sep 18 05:15:25 2008 From: joe at sumless.net (Joe Blanchard) Date: Thu, 18 Sep 2008 06:15:25 -0400 Subject: Procedure to Change Nameservers Message-ID: <018201c91977$792cedc0$1401a8c0@E520> Typical answer from an uneducated DNS expert. Jo Rhetts comments and experience are simplistic in nature and uselss at best. Given that your SOA DNS is one it would be quite simple to do so. If the Domains in question are SOA'd at many different sources than I would say you have a bit a work in front of you. You would have to contact each of the SOAs and change them. If your sourcing your own SOA than its simple. Contact me off list and we can discuss the details. Cheers, -Joe Blanchard > > > -----Original Message----- > > From: Jo Rhett [mailto:jrhett at netconsonance.com] > > Sent: Thursday, September 18, 2008 5:45 AM > > To: Crist Clark > > Cc: Nanog > > Subject: Re: Procedure to Change Nameservers > > > > On Sep 16, 2008, at 3:50 PM, Crist Clark wrote: > > > I want to change the nameservers for a bunch of domains > > > > Then ask the question on a list related to DNS. > > > > -- > > Jo Rhett > > Net Consonance : consonant endings by net philanthropy, open source > > and other randomness > > > > From cayle.spandon at gmail.com Thu Sep 18 08:51:55 2008 From: cayle.spandon at gmail.com (Cayle Spandon) Date: Thu, 18 Sep 2008 09:51:55 -0400 Subject: Mechanisms for a multi-homed host to pick the best router In-Reply-To: References: <71c13900809171932m477b5d51jf0e0f9883546e3c3@mail.gmail.com> Message-ID: <71c13900809180651m115bfd85n93aa5acea7b03c00@mail.gmail.com> Hi Paul, Thank you very much for the confirmation that the idea is sane and for the pointers to the additional information. -- Cayle On Wed, Sep 17, 2008 at 11:49 PM, Paul Vixie wrote: > cayle.spandon at gmail.com ("Cayle Spandon") writes: > > > (My apologies, in advance, for the fact that this question is very long > > winded.) > > np. > > > I have a server which is multi-homed to N routers as shown below: > > > > +---+ > > R1---| | > > | | > > R2---| | > > ... | S | > > | | > > Rn---| | > > +---+ > > > > This server is a host; it is not a router in the sense that it will never > > forward any packets (but it might run routing protocols as discussed > below). > > > > Also, for the sake of simplicity in this discussion, let's say this > server > > only receives inbound TCP connections; it never initiates outbound TCP > > connections. > > > > Finally, this server has a loopback address L. All traffic destined to > the > > server uses address L as the destination address. All N routers have a > > static route to L and inject that route into their routing protocol > > (possibly as part of an aggregate). > > > > Now, imagine the server receives an inbound connection from another host > > whose address is A. Thus, the TCP SYN packet which S receives has source > > address A and destination address L. > ... > > For all these reasons, I don't want to run BGP on the server. > > "too many moving parts." > > > Someone suggested an idea to me which seems almost to simple to work, but > I > > cannot find any good reason why it would not work. > > > > The idea is "the server simply sends all outbound traffic for the TCP > > connection out over the same interface over which the most recent TCP > > traffic for that connection was received". > > > > So, for example, if the server receives the SYN from router R3, it would > > send the SYN ACK and all subsequent packets for the TCP connection over > that > > same interface R3. > > ... > > right idea. works great. see the following: > > http://www.academ.com/nanog/feb1997/multihoming.html > http://www.irbs.net/internet/nanog/9706/0232.html > http://gatekeeper.dec.com/pub/misc/vixie/ifdefault/ > > > ... > > I can think of the following problems with this approach: > > > > (Problem 1) It only works for inbound TCP connections and not for > outbound > > TCP connections. For outbound TCP connections we would not know which > router > > to send the first SYN packet to. > > you said above you only needed inbound. for outbound and udp: round robin. > > > ... > > My question for the NANOG community are these: > > > > (Question 1) Can you think of any additional problems with this approach? > > Specifically, I am interested in persistent failures in the absence of > > topology changes. > > topology change frequency is in a different order of magnitude than the > usual tcp session startup frequency, so unless you've got long running tcp > sessions which won't restart on a connection reset, you've got no problem, > and if you do have that kind of tcp session, you've already got problems. > > > (Question 2) Is there another mechanism for the server (a multi-homed > host) > > to pick a best router, short of running stub BGP? Are there any standards > > for this? > > there are a bazillion patented and/or ubersecret ways to do this. noone > has > ever demonstrated anything that works better than an undercommitted network > with undercommitted connections to other undercommitted first-hop networks. > > > (Question 3) If the answer to question 2 is "no", is there any interest > > in standardizing a protocol for a multi-homed host to pick a best > > next-hop router? One could think of this is a host-to-router routing > > protocol. One might call the existing routing protocols router-to-router > > protocols (because I think we are abusing them by running them on > > hosts). This is somewhat analogous to the multicast routing world where > > we use different protocols for router-to-router multicast (PIM) versus > > host-to-router (IGMP). > > sadly, this has been tried, but it always runs into least-cost routing > issues > whereby not only the predicted connection quality but also contract details > like whether this is over or under the per-period minima and how many > quatloos > per kilosegment it will cost all have to get exchanged at high speed with > low > latency and good accuracy. been there, did that, got no useful t-shirt > even. > -- > Paul Vixie > > From cayle.spandon at gmail.com Thu Sep 18 08:54:54 2008 From: cayle.spandon at gmail.com (Cayle Spandon) Date: Thu, 18 Sep 2008 09:54:54 -0400 Subject: Mechanisms for a multi-homed host to pick the best router In-Reply-To: <48D1C007.9060005@cox.net> References: <71c13900809171932m477b5d51jf0e0f9883546e3c3@mail.gmail.com> <48D1C007.9060005@cox.net> Message-ID: <71c13900809180654l2e0c19afv44e7efc4b29d04a@mail.gmail.com> Hi Laurence, RE> why would you not sent the reply out the same spigot you go the request on? Yes, that exactly what I was trying to ask in the e-mail (in a much more verbose way than you :-). The problems I could think of are: - It only works for inbound TCP connections. - The TCP connections might be dropped after a topology change despite the existence of an alternative path. I was wondering if anyone else knows of any additional problems. -- Cayle From patrick at ianai.net Thu Sep 18 09:42:13 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 18 Sep 2008 10:42:13 -0400 Subject: Atrivo/Intercage: Now Only 1 Upstream In-Reply-To: <48D16396.8040309@everydns.net> References: <982D8D05B6407A49AD506E6C3AC8E7D6BD9A9D7281@caralain.haven.nynaeve.net> <75cb24520809171007v6282c6b4wd02f6ca1bffd2bf@mail.gmail.com> <48D13F11.6050600@everydns.net> <675EC3C8-730F-475B-AB07-AEA3C352C669@ianai.net> <48D16396.8040309@everydns.net> Message-ID: <7BB9706A-7E8C-442F-BE74-F298318F5B55@ianai.net> On Sep 17, 2008, at 4:07 PM, David Ulevitch wrote: > Patrick W. Gilmore wrote: >> On Sep 17, 2008, at 1:32 PM, David Ulevitch wrote: > >>> At the end of the day, nobody is going to drop packets for >>> amazon's IP space. >> I'm afraid reality disagrees with you - there already are networks >> doing it. >> Being big does not guarantee you ability to do Bad Things. > > I didn't imply that it did. Actually, that is exactly what you did. > But the ability to block without causing significant collateral > damage becomes more and more difficult as IPs become less tied to > the organization using them. True (and rather obvious). Here's another obviously true statement: As more & more spam comes from a set of IP addresses, it becomes less & less likely you should accept e-mail from that space. > That said, you're right that people are doing it now. Consensus > from friends running their apps on EC2 is that you can't expect to > be able to send any email from EC2 and hope for a high > deliverability rate. Not news to anyone who works on anti-spam or e-mail deliverability. Perhaps the collateral damage will force Amazon to get things fixed faster. Or maybe not, but either way I don't see how you can blame someone for not wanting to accept e-mail from EC2. -- TTFN, patrick From pstewart at nexicomgroup.net Thu Sep 18 10:01:47 2008 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Thu, 18 Sep 2008 11:01:47 -0400 Subject: Seattle Peering In-Reply-To: <7BB9706A-7E8C-442F-BE74-F298318F5B55@ianai.net> References: <982D8D05B6407A49AD506E6C3AC8E7D6BD9A9D7281@caralain.haven.nynaeve.net> <75cb24520809171007v6282c6b4wd02f6ca1bffd2bf@mail.gmail.com> <48D13F11.6050600@everydns.net><675EC3C8-730F-475B-AB07-AEA3C352C669@ianai.net><48D16396.8040309@everydns.net> <7BB9706A-7E8C-442F-BE74-F298318F5B55@ianai.net> Message-ID: <89D27DE3375BB6428DDCC2927489826A0198D4C5@nexus.nexicomgroup.net> Hi folks... We're working on some plans to peer in the Seattle area. Choices so far considered are SIX and PAIX Seattle pretty much.... I was of the impression that if you get a port on one of these exchanges, you can connect to the other one as well? Just looking for clarification from folks who are connected out there..;) Any charges to go between the exchanges or it just included? 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 mksmith at adhost.com Thu Sep 18 10:36:58 2008 From: mksmith at adhost.com (Michael K. Smith) Date: Thu, 18 Sep 2008 08:36:58 -0700 Subject: Seattle Peering In-Reply-To: <89D27DE3375BB6428DDCC2927489826A0198D4C5@nexus.nexicomgroup.net> Message-ID: Hello Paul: On 9/18/08 8:01 AM, "Paul Stewart" wrote: > Hi folks... > > We're working on some plans to peer in the Seattle area. Choices so far > considered are SIX and PAIX Seattle pretty much.... > > I was of the impression that if you get a port on one of these > exchanges, you can connect to the other one as well? Just looking for > clarification from folks who are connected out there..;) Any charges to > go between the exchanges or it just included? > Speaking from the SIX side, there is no charge to connect to the fabric if you supply the optics, and there is a one-time fiber cross connect charge of $200.00 US. The SIX and PAIX are directly connected and you can peer across the fabric. The SIX page is http://www.seattleix.net for more info or you can email me directly. I have no idea about charges related to PAIX. Mike SIX Tech Guy Hat On From Valdis.Kletnieks at vt.edu Thu Sep 18 11:15:07 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 18 Sep 2008 12:15:07 -0400 Subject: Mechanisms for a multi-homed host to pick the best router In-Reply-To: Your message of "Wed, 17 Sep 2008 22:32:29 EDT." <71c13900809171932m477b5d51jf0e0f9883546e3c3@mail.gmail.com> References: <71c13900809171932m477b5d51jf0e0f9883546e3c3@mail.gmail.com> Message-ID: <18053.1221754507@turing-police.cc.vt.edu> On Wed, 17 Sep 2008 22:32:29 EDT, Cayle Spandon said: > (Problem 2) If there is a topology change after the TCP connection has been > established, the traffic might follow a sub-optimal path. Another possibility is that the connection was originally established *during* a link outage, so the initial part of the connection was done over a sub-optimal path, and that the topology change puts it back to the normal better path... A possible *biggger* issue is that "toss the reply packet back where the original came from" makes traffic-engineering your outbound packets a lot more challenging - you end up having to play announcement games upstream of your N routers to engineer your *inbound* traffic so your outbound packets do what you want. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From marla.azinger at frontiercorp.com Thu Sep 18 11:17:07 2008 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Thu, 18 Sep 2008 12:17:07 -0400 Subject: LoA (Letter of Authorization) for Prefix Filter Modification? In-Reply-To: <200809171622.m8HGMKTI064265@aurora.sol.net> References: <48D0BEA1.2040603@ipax.at> from "Raoul Bhatia [IPAX]" at Sep 17, 2008 10:24:01 AM <200809171622.m8HGMKTI064265@aurora.sol.net> Message-ID: <2E2FECEBAE57CC4BAACDE67638305F1048120B7DF2@ROCH-EXCH1.corp.pvt> I use RWHOIS for proof of who we assign and allocate address space to. I dont believe an LOA is any more valid or secure than my RWHOIS data base that I keep and update on a daily basis. In this case I find it a waste of time when people ask me for LOA's when they can verify the info on my RWHOIS site. And I point these people to my RWHOIS site when they ask for LOA as opposed to wasting my time on creating paperwork. However, if you dont have something like that set up, then I do see the value in people asking for LOA and thus helping to ensure address space isnt getting hijacked. My 2 cents Marla Azinger Frontier Communications -----Original Message----- From: Joe Greco [mailto:jgreco at ns.sol.net] Sent: Wednesday, September 17, 2008 9:22 AM To: Raoul Bhatia [IPAX] Cc: nanog at nanog.org Subject: Re: LoA (Letter of Authorization) for Prefix Filter Modification? > Joe Greco wrote: > > How do you verify the authenticity of anything? This is a common > > problem in the Real World, and is hardly limited to LoA's. > > > > How do you prove that what was on Pages 1 to (N-1) of an N page > > contract contained the words you think they said? I knew a guy, > > back in the early days, who habitually changed the SLA's in his > > contracts so that he could cancel a contract for virtually no reason > > at all ... the folly of mailing around contracts as .doc files in > > e-mail. But even failing that, it's pretty trivial to reprint a > > document, so where do you stop, do you use special paper, special > > ink, watermarking of documents, initial each page, all of the above, etc? > > what about using a digital signation of e.g. a pdf version of a scan? Try putting that up next to an apparently legitimate but actually subtly modified paper contract with signatures, in a court of law, and feel free to inform us of which one the court finds more compelling. In an environment where there's an established history and standard procedures, they're typically going to prefer the familiar method. In our world, if we were to have some sort of crypto-based way to have a netblock owner sign something like that, yeah, that'd be great, and it would mean that the community would generally be able to manage the issue without having to resort to faxed-around LoA's, etc., but we don't have that infrastructure, or even a common/widespread LoA system. Sigh. I'm not arguing that some sort of technical/crypto infrastructure for authorizing the advertisement of space shouldn't be developed, and in fact I think it should. However, as an interim step, things like LoA's are much better than nothing at all, and worrying about the authenticity of an LoA is probably not worth the time and effort, given the way these things tend to work out. If there's cause for concern, those who are receiving the LoA's will ramp up the paranoia. ... 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 stephen at sprunk.org Thu Sep 18 12:02:15 2008 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 18 Sep 2008 12:02:15 -0500 Subject: LoA (Letter of Authorization) for Prefix Filter Modification? In-Reply-To: <2E2FECEBAE57CC4BAACDE67638305F1048120B7DF2@ROCH-EXCH1.corp.pvt> References: <48D0BEA1.2040603@ipax.at> from "Raoul Bhatia [IPAX]" at Sep 17, 2008 10:24:01 AM <200809171622.m8HGMKTI064265@aurora.sol.net> <2E2FECEBAE57CC4BAACDE67638305F1048120B7DF2@ROCH-EXCH1.corp.pvt> Message-ID: <48D28997.4000109@sprunk.org> Azinger, Marla wrote: > I use RWHOIS for proof of who we assign and allocate address space to. I dont believe an LOA is any more valid or secure than my RWHOIS data base that I keep and update on a daily basis. In this case I find it a waste of time when people ask me for LOA's when they can verify the info on my RWHOIS site. And I point these people to my RWHOIS site when they ask for LOA as opposed to wasting my time on creating paperwork. However, if you dont have something like that set up, then I do see the value in people asking for LOA and thus helping to ensure address space isnt getting hijacked. > How is _you_ showing information in an RWHOIS server that _you_ control in any way proving that the holder of a address block is authorizing _you_ to advertise it on their behalf? It is not unreasonable for your upstreams to ask for some proof _from the holder_ rather than simply trusting you. For all they know, you're just hijacking random address space and putting it in your RWHOIS server. Would you be happy if some random Tier 1 started letting _their_ customers advertise _your_ address space, just because those customers had put up an RWHOIS server claiming it was theirs? This is not about asking you for an LoA for your own address space, which any moron can follow in a reasonably trustworthy chain from ARIN to you. It's about address space that is _not_ directly registered to the company trying to get a filter exception. S From ww at styx.org Thu Sep 18 12:58:27 2008 From: ww at styx.org (William Waites) Date: Thu, 18 Sep 2008 19:58:27 +0200 Subject: Mechanisms for a multi-homed host to pick the best router In-Reply-To: References: <71c13900809171932m477b5d51jf0e0f9883546e3c3@mail.gmail.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> So, for example, if the server receives the SYN from router R3, it >> would >> send the SYN ACK and all subsequent packets for the TCP connection >> over that >> same interface R3. >> ... > > right idea. works great. see the following: > > http://www.academ.com/nanog/feb1997/multihoming.html > http://www.irbs.net/internet/nanog/9706/0232.html > http://gatekeeper.dec.com/pub/misc/vixie/ifdefault/ This approach is particularly useful for host with multiple IPv6 tunnels. Some tunnel providers implement strict RPF, some don't. Where this is the case, having multiple tunnels (cf multiple address ranges) is problematic. Of course these days perhaps perhaps the IPv4 variant could be done with a stateful NAT. Maybe case could be made for IPv6 NAT (and site-local addresses?) in this scnario... - -w - -- William Waites http://www.irl.styx.org/ +49 30 8894 9942 CD70 0498 8AE4 36EA 1CD7 281C 427A 3F36 2130 E9F5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkjSlsMACgkQQno/NiEw6fWEhACfcVGZ5qEbvESVCWxQibkm/jLp wKsAn1lQWcMO+fk5ZV5V08narSfoC/gF =tlbx -----END PGP SIGNATURE----- From jra at baylink.com Thu Sep 18 18:31:37 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Thu, 18 Sep 2008 19:31:37 -0400 (EDT) Subject: Procedure to Change Nameservers In-Reply-To: <48CFD5D1.8C45.0097.0@globalstar.com> Message-ID: <17789044.4321221780697409.JavaMail.root@benjamin.vicimarketing.com> ----- "Crist Clark" wrote: > I want to change the nameservers for a bunch of domains. Really, > all I want to do is change the IP address, but it seems easier > just to change both the name and IP to avoid any possibility of > confusion. However, I am not "physically" moving the services. > These are the same physical servers, just an additional IP address > assigned to the appropriate interface. I want to do this the > "right" way. > Not really too bad. At least we don't have to send in host > record templates anymore. In fact, some registrars do require that they have the new zone nameserver names and IP addresses registered, at least with themselves, and if it's a new zone, you may not be able to put them inside the zone on first setup; Domain Discover just did this to me on a change, and I believe I've had the latter happen to me as well: the automated system wanted to *validate* the IP to name mapping in... um, DNS. For a new domain. Which wasn't up yet. 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 Sep 18 18:41:29 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Thu, 18 Sep 2008 19:41:29 -0400 (EDT) Subject: Procedure to Change Nameservers In-Reply-To: <20080917111250.GA28166@pwns.ms> Message-ID: <27502685.4371221781289600.JavaMail.root@benjamin.vicimarketing.com> ----- list-nanog at pwns.ms wrote: > > Free sites that perform similar DNS configuration checks that I know > of > > are: > > > > http://dnssy.com > > http://www.intodns.com > > Just to add to the list: > http://squish.net/dnscheck/ Wow. Nice one. All three added to wiki.outages.org. 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 bmanning at vacation.karoshi.com Thu Sep 18 21:57:35 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 19 Sep 2008 02:57:35 +0000 Subject: Procedure to Change Nameservers In-Reply-To: <17789044.4321221780697409.JavaMail.root@benjamin.vicimarketing.com> References: <48CFD5D1.8C45.0097.0@globalstar.com> <17789044.4321221780697409.JavaMail.root@benjamin.vicimarketing.com> Message-ID: <20080919025735.GA4843@vacation.karoshi.com.> On Thu, Sep 18, 2008 at 07:31:37PM -0400, Jay R. Ashworth wrote: > ----- "Crist Clark" wrote: > > I want to change the nameservers for a bunch of domains. Really, > > all I want to do is change the IP address, but it seems easier > > just to change both the name and IP to avoid any possibility of > > confusion. However, I am not "physically" moving the services. > > These are the same physical servers, just an additional IP address > > assigned to the appropriate interface. I want to do this the > > "right" way. > > > Not really too bad. At least we don't have to send in host > > record templates anymore. > > In fact, some registrars do require that they have the new zone nameserver > names and IP addresses registered, at least with themselves, and if it's a > new zone, you may not be able to put them inside the zone on first setup; > Domain Discover just did this to me on a change, and I believe I've had the > latter happen to me as well: the automated system wanted to *validate* the > IP to name mapping in... um, DNS. > > For a new domain. > > Which wasn't up yet. > > > > Cheers, > -- jra well, wearing my oldschool hat, the service should be working on the authoritative servers -prior- to asking the parent to jump in - do some work - and send me a bill. validation can work just fine w/ address literals. --bill From pbg at cs.berkeley.edu Fri Sep 19 01:00:14 2008 From: pbg at cs.berkeley.edu (Brighten Godfrey) Date: Thu, 18 Sep 2008 23:00:14 -0700 Subject: Mechanisms for a multi-homed host to pick the best router Message-ID: <24C8708A-5E39-4594-AFBC-1368A414D176@cs.berkeley.edu> > When the server sends TCP traffic for that same connection back to > host A, > it needs to pick one of the N routers, in other words, it needs to > pick an > outbound interface from its N interfaces. ... > The problem is that some routers are "better" than other routers in > the > sense that they are closer to the final destination address A. (For > example, > each router could be connected to a different ISP.) > > One way for the server to pick the "optimal" downstream router, is > to run > "stub BGP" between the server and each of the routers. ... > While this approach would certainly allow the server to pick the > optimal > downstream router in all cases, I would prefer not to run routing > protocols > on this server for a number of reasons: It's probably good to keep in mind that this would be "optimal", not optimal. As far as I know the best you would get is to minimize the number of AS hops, which is probably correlated with, but definitely not the same as, metrics you actually care about like latency. All in all, running BGP does seem like an awful lot of work just to let you optimize for the wrong metric. Here's another thought, though. You don't need to run BGP to get the data that BGP will give you. There exist approximate maps of the Internet at the router or AS level with IP prefixes attached. It would be possible to periodically obtain one of these graphs, e.g. from CAIDA, and then run a shortest-paths algorithm on that graph to decide based on the destination IP address which router is best. Not only does this let you avoid running BGP, it also saves memory since you need only one copy of the graph, rather than one copy for each of the N BGP sessions. Of course, it's not real-time data, but if all you need is a good guess as to which of the outbound interfaces is best, it might be sufficient. Does anyone actually do something like this in practice? (I'm guessing no) > Someone suggested an idea to me which seems almost to simple to > work, but I > cannot find any good reason why it would not work. > > The idea is "the server simply sends all outbound traffic for the TCP > connection out over the same interface over which the most recent TCP > traffic for that connection was received". So the underlying idea here is that the source (or its ISP) has effectively done the work of picking a good path, and by replying on the same interface, you use the reverse of that path, which is also likely to be pretty good. Some of the assumptions in that reasoning seem imperfect: - There's a good chance the forward path (i.e. the one the source picked) isn't the best. - Asymmetry, as you noted: Even if the forward path was the best, the reverse of it is not necessarily the best. - A different asymmetry: Even if the forward was best and the reverse of it is best, the path followed by sending on the same interface is not necessarily the reverse of the forward path. So I understand that this heuristic could perform pretty well in practice, and certainly better than sending on a random interface (in terms of latency, not traffic engineering). But I can't see how it's the optimal strategy. I think there are commercial products that solve this problem the "right" way, by automatically and dynamically monitoring path quality and availability, and selecting paths for you. I think the Avaya Converged Network Analyzer is one. I recall speaking with an operator from a major content provider who said that they use an intelligent route selection product similar to this for their outbound traffic. I'd be personally interested to hear what other operators typically use. ~Brighten Godfrey From tom at snnap.net Fri Sep 19 01:49:11 2008 From: tom at snnap.net (Tom Storey) Date: Fri, 19 Sep 2008 15:49:11 +0900 (EIT) Subject: Anyone have experience with Alcatel 9500MXC? Message-ID: <56831.172.25.144.4.1221806951.squirrel@imap.snnap.net> Hi all. I have several of these units deployed, they are all running fine, but I am looking for information about them, specifically SNMP related. Our Alcatel contacts have given us a collection of MIBs, from which I cant really get anything useful out of the radios. Other than that they dont seem too hell bent on providing much further help on this subject. Hoping someone else on here might have experience with these units and can share some information about how to get useful information out of them via SNMP, like traffic and error counters, signal parameters, alarm status, etc. Cheers, Tom From karnaugh at karnaugh.za.net Fri Sep 19 01:55:58 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Fri, 19 Sep 2008 08:55:58 +0200 Subject: Anyone have experience with Alcatel 9500MXC? In-Reply-To: <56831.172.25.144.4.1221806951.squirrel@imap.snnap.net> References: <56831.172.25.144.4.1221806951.squirrel@imap.snnap.net> Message-ID: <48D34CFE.40902@karnaugh.za.net> Tom Storey wrote: > Hi all. > > I have several of these units deployed, they are all running fine, but I > am looking for information about them, specifically SNMP related. > > Our Alcatel contacts have given us a collection of MIBs, from which I cant > really get anything useful out of the radios. Other than that they dont > seem too hell bent on providing much further help on this subject. > > Hoping someone else on here might have experience with these units and can > share some information about how to get useful information out of them via > SNMP, like traffic and error counters, signal parameters, alarm status, > etc. Excuse my ignorance (never touched such a device) but would doing an snmpwalk over the device not help? MIB's for traffic on interfaces should be fairly standard unless Alcatel smoked their socks. From cholland at rnmd.net Fri Sep 19 03:27:49 2008 From: cholland at rnmd.net (Craig Holland) Date: Fri, 19 Sep 2008 03:27:49 -0500 Subject: Sprint/Cogent Peering Issue? Message-ID: <3FEEC5BE16966148B912DEB0FF34C81C70FC63@BE09.exg4.exghost.com> Hi, We are seeing traffic getting dropped between our Cogent and Sprint connect DC's. One of them is getting shutdown, so we just have a Cogent link there :| Anyone seeing anything similar? From: 91.102.40.18 traceroute to ops1.scc.rnmd.net (208.91.188.136), 30 hops max, 38 byte packets 1 v1-core-sw1 (91.102.40.5) 0.471 ms 0.422 ms 0.431 ms 2 ge-0-1-0-pat2 (91.102.40.146) 0.376 ms 0.354 ms 0.335 ms 3 fe-1-3-1-501-pat1 (91.102.40.208) 0.376 ms 0.344 ms 0.407 ms 4 vl324.mpd01.lon01.atlas.cogentco.com (149.6.147.217) 0.745 ms 0.744 ms 0.740 ms 5 te3-1.mpd02.lon01.atlas.cogentco.com (130.117.2.26) 0.717 ms 39.037 ms te1-8.ccr01.lon01.atlas.cogentco.com (130.117.3.226) 0.565 ms 6 gi6-0-0.core01.lon01.atlas.cogentco.com (130.117.1.73) 0.592 ms 0.450 ms 0.483 ms 7 213.206.131.29 (213.206.131.29) 0.581 ms 0.503 ms 0.483 ms 8 sl-bb21-lon-3-0.sprintlink.net (213.206.129.152) 1.078 ms 0.905 ms 0.934 ms 9 * >From 208.91.188.138 traceroute to ops2.lnc.rnmd.net (91.102.40.18), 30 hops max, 38 byte packets 1 v1-core-sw1 (208.91.188.130) 0.600 ms 0.456 ms 2.105 ms 2 f0-0-4-0-pat2 (207.0.21.114) 0.416 ms 0.466 ms 0.486 ms 3 sl-st1-sc-2-6.sprintlink.net (144.228.111.25) 0.455 ms 0.224 ms 0.236 ms 4 sl-crs2-sj-0-1-0-3.sprintlink.net (144.232.20.196) 1.482 ms 1.477 ms 1.232 ms 5 sl-st20-sj-12-0-0.sprintlink.net (144.232.20.63) 2.482 ms 2.472 ms 2.485 ms 6 po5-3.core01.sjc03.atlas.cogentco.com (154.54.13.49) 2.732 ms 2.472 ms 2.485 ms 7 te3-1.mpd01.sjc03.atlas.cogentco.com (154.54.6.85) 2.705 ms 2.723 ms 2.735 ms 8 vl3493.ccr02.sjc01.atlas.cogentco.com (154.54.6.109) 3.231 ms vl3492.mpd01.sjc01.atlas.cogentco.com (154.54.6.105) 3.227 ms vl3491.ccr02.sjc01.atlas.cogentco.com (154.54.6.101) 2.726 ms 9 te9-3.mpd01.sfo01.atlas.cogentco.com (154.54.2.53) 3.968 ms 3.722 ms te8-3.ccr02.sfo01.atlas.cogentco.com (154.54.2.137) 3.988 ms 10 te9-2.ccr02.mci01.atlas.cogentco.com (154.54.24.118) 50.943 ms te7-4.mpd01.mci01.atlas.cogentco.com (154.54.24.106) 50.944 ms 50.720 ms 11 te9-3.ccr02.ord01.atlas.cogentco.com (154.54.25.78) 50.669 ms 63.423 ms te9-3.mpd01.ord01.atlas.cogentco.com (154.54.25.82) 51.206 ms 12 te2-1.ccr02.bos01.atlas.cogentco.com (154.54.7.170) 78.172 ms te3-3.mpd01.bos01.atlas.cogentco.com (154.54.7.82) 100.666 ms te2-1.ccr02.bos01.atlas.cogentco.com (154.54.7.170) 78.176 ms 13 * * * Thanks, craig ________________________ Craig Holland Rhythm NewMedia Sr. Director Operations & Integration YIM: cholland From roy at gnomon.org.uk Fri Sep 19 04:57:41 2008 From: roy at gnomon.org.uk (Roy Badami) Date: Fri, 19 Sep 2008 10:57:41 +0100 Subject: Sprint/Cogent Peering Issue? In-Reply-To: <3FEEC5BE16966148B912DEB0FF34C81C70FC63@BE09.exg4.exghost.com> References: <3FEEC5BE16966148B912DEB0FF34C81C70FC63@BE09.exg4.exghost.com> Message-ID: <18643.30613.428941.158081@giles.gnomon.org.uk> I'm seeing issues with traceroutes dying at Sprint in London, too. >From our site here in the UK (transit from NTL Telewest Business) I can't reach cisco.com (but I know cisco.com is up - I can reach it from elsewhere). Apparently customers of XS4ALL in the Netherlands are seeing similar behaviour. -roy 1 c1-cam-gi-0-0-100 (172.16.128.2) 0.839 ms 0.470 ms 0.405 ms 2 ntl-gw1-fa-0-0 (82.1.12.129) 1.975 ms 1.804 ms 1.517 ms 3 nrth-lam-1-multilink26.network.virginmedia.net (62.253.60.221) 11.926 ms 4.612 ms 3.921 ms 4 nrth-t3core-1a-so-700-0.network.virginmedia.net (213.106.255.25) 5.102 ms 11.540 ms 9.283 ms 5 nth-bb-a-so-210-0.network.virginmedia.net (212.43.162.237) 4.833 ms 7.680 ms 5.126 ms 6 gfd-bb-b-so-010-0.network.virginmedia.net (62.253.185.98) 9.787 ms 7.746 ms 8.956 ms 7 sl-gw11-lon-11-0.sprintlink.net (213.206.156.101) 15.766 ms 12.921 ms 9.373 ms 8 sl-bb21-lon-11-0.sprintlink.net (213.206.128.58) 19.495 ms 9.444 ms 10.447 ms 9 * * * 10 * * * 11 * * * From tme at multicasttech.com Fri Sep 19 05:02:37 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 19 Sep 2008 06:02:37 -0400 Subject: Sprint/Cogent Peering Issue? In-Reply-To: <3FEEC5BE16966148B912DEB0FF34C81C70FC63@BE09.exg4.exghost.com> References: <3FEEC5BE16966148B912DEB0FF34C81C70FC63@BE09.exg4.exghost.com> Message-ID: No apparent problems from Cogent in Northern Virginia : tme$ traceroute ops1.scc.rnmd.net traceroute to ops1.scc.rnmd.net (208.91.188.136), 64 hops max, 40 byte packets 1 dmz-mct2 (63.105.122.1) 0.754 ms 0.278 ms 0.485 ms 2 gi0-7.na21.b002176-1.dca01.atlas.cogentco.com (38.99.206.153) 0.741 ms 0.612 ms 0.753 ms 3 gi2-1.3587.core01.dca01.atlas.cogentco.com (38.20.32.13) 14.444 ms 0.756 ms 0.728 ms 4 te3-1.ccr02.dca01.atlas.cogentco.com (154.54.3.158) 0.980 ms 1.067 ms 0.978 ms 5 vl3493.mpd01.dca02.atlas.cogentco.com (154.54.7.230) 46.711 ms te4-1.mpd01.dca02.atlas.cogentco.com (154.54.2.182) 2.400 ms te7-3.mpd01.dca02.atlas.cogentco.com (154.54.6.26) 1.863 ms 6 vl3494.mpd01.iad01.atlas.cogentco.com (154.54.5.42) 1.935 ms vl3496.mpd01.iad01.atlas.cogentco.com (154.54.5.46) 1.968 ms vl3497.mpd01.iad01.atlas.cogentco.com (154.54.5.66) 1.618 ms 7 gi9-0-0.core01.iad01.atlas.cogentco.com (154.54.3.221) 1.578 ms gi14-0-0.core01.iad01.atlas.cogentco.com (154.54.5.57) 1.840 ms gi2-0-0.core01.iad01.atlas.cogentco.com (154.54.5.33) 1.788 ms 8 sprint.iad01.atlas.cogentco.com (154.54.13.62) 1.657 ms 1.693 ms 1.713 ms 9 sl-crs1-rly-0-4-5-0.sprintlink.net (144.232.20.154) 3.725 ms 3.597 ms 3.724 ms 10 sl-crs2-sj-0-5-0-0.sprintlink.net (144.232.20.186) 70.442 ms 70.780 ms 70.417 ms 11 sl-st1-sc-1-1.sprintlink.net (144.232.20.197) 70.672 ms 70.844 ms 70.973 ms 12 sl-rhyth2-158722-0.sprintlink.net (144.228.111.26) 71.197 ms 71.128 ms 70.935 ms 13 208.91.188.68 (208.91.188.68) 71.213 ms 71.381 ms 71.172 ms 14 ops1.scc.rnmd.net (208.91.188.136) 71.412 ms 71.497 ms 71.673 ms Regards Marshall On Sep 19, 2008, at 4:27 AM, Craig Holland wrote: > Hi, > > We are seeing traffic getting dropped between our Cogent and Sprint > connect DC's. One of them is getting shutdown, so we just have a > Cogent > link there :| Anyone seeing anything similar? > > From: 91.102.40.18 > traceroute to ops1.scc.rnmd.net (208.91.188.136), 30 hops max, 38 byte > packets > 1 v1-core-sw1 (91.102.40.5) 0.471 ms 0.422 ms 0.431 ms > 2 ge-0-1-0-pat2 (91.102.40.146) 0.376 ms 0.354 ms 0.335 ms > 3 fe-1-3-1-501-pat1 (91.102.40.208) 0.376 ms 0.344 ms 0.407 ms > 4 vl324.mpd01.lon01.atlas.cogentco.com (149.6.147.217) 0.745 ms > 0.744 ms 0.740 ms > 5 te3-1.mpd02.lon01.atlas.cogentco.com (130.117.2.26) 0.717 ms > 39.037 ms te1-8.ccr01.lon01.atlas.cogentco.com (130.117.3.226) > 0.565 ms > 6 gi6-0-0.core01.lon01.atlas.cogentco.com (130.117.1.73) 0.592 ms > 0.450 ms 0.483 ms > 7 213.206.131.29 (213.206.131.29) 0.581 ms 0.503 ms 0.483 ms > 8 sl-bb21-lon-3-0.sprintlink.net (213.206.129.152) 1.078 ms 0.905 > ms > 0.934 ms > 9 * > >> From 208.91.188.138 > traceroute to ops2.lnc.rnmd.net (91.102.40.18), 30 hops max, 38 byte > packets > 1 v1-core-sw1 (208.91.188.130) 0.600 ms 0.456 ms 2.105 ms > 2 f0-0-4-0-pat2 (207.0.21.114) 0.416 ms 0.466 ms 0.486 ms > 3 sl-st1-sc-2-6.sprintlink.net (144.228.111.25) 0.455 ms 0.224 ms > 0.236 ms > 4 sl-crs2-sj-0-1-0-3.sprintlink.net (144.232.20.196) 1.482 ms 1.477 > ms 1.232 ms > 5 sl-st20-sj-12-0-0.sprintlink.net (144.232.20.63) 2.482 ms 2.472 > ms > 2.485 ms > 6 po5-3.core01.sjc03.atlas.cogentco.com (154.54.13.49) 2.732 ms > 2.472 ms 2.485 ms > 7 te3-1.mpd01.sjc03.atlas.cogentco.com (154.54.6.85) 2.705 ms 2.723 > ms 2.735 ms > 8 vl3493.ccr02.sjc01.atlas.cogentco.com (154.54.6.109) 3.231 ms > vl3492.mpd01.sjc01.atlas.cogentco.com (154.54.6.105) 3.227 ms > vl3491.ccr02.sjc01.atlas.cogentco.com (154.54.6.101) 2.726 ms > 9 te9-3.mpd01.sfo01.atlas.cogentco.com (154.54.2.53) 3.968 ms 3.722 > ms te8-3.ccr02.sfo01.atlas.cogentco.com (154.54.2.137) 3.988 ms > 10 te9-2.ccr02.mci01.atlas.cogentco.com (154.54.24.118) 50.943 ms > te7-4.mpd01.mci01.atlas.cogentco.com (154.54.24.106) 50.944 ms > 50.720 > ms > 11 te9-3.ccr02.ord01.atlas.cogentco.com (154.54.25.78) 50.669 ms > 63.423 ms te9-3.mpd01.ord01.atlas.cogentco.com (154.54.25.82) > 51.206 ms > 12 te2-1.ccr02.bos01.atlas.cogentco.com (154.54.7.170) 78.172 ms > te3-3.mpd01.bos01.atlas.cogentco.com (154.54.7.82) 100.666 ms > te2-1.ccr02.bos01.atlas.cogentco.com (154.54.7.170) 78.176 ms > 13 * * * > > Thanks, > craig > > ________________________ > Craig Holland > Rhythm NewMedia > Sr. Director Operations & Integration > YIM: cholland > > > From andy-nanog at bash.sh Fri Sep 19 05:43:04 2008 From: andy-nanog at bash.sh (Andrew Mulholland) Date: Fri, 19 Sep 2008 11:43:04 +0100 Subject: Sprint/Cogent Peering Issue? In-Reply-To: References: <3FEEC5BE16966148B912DEB0FF34C81C70FC63@BE09.exg4.exghost.com> Message-ID: <20080919104304.GC20958@waffl.ing.me.uk> On Fri, Sep 19, 2008 at 06:02:37AM -0400, Marshall Eubanks wrote: > No apparent problems from Cogent in Northern Virginia : Fine from Cogent in DC. Not so fine from Cogent in the Netherlands. traceroute to ops1.scc.rnmd.net (208.91.188.136), 64 hops max, 40 byte packets 1 38.105.91.2 (38.105.91.2) [AS174] 0 ms 0 ms 0 ms 2 gi0-1.na32.b001806-1.dca01.atlas.cogentco.com (38.104.30.101) [AS174] 1 ms 1 ms 2 ms 3 te9-3.3596.ccr02.dca01.atlas.cogentco.com (38.20.37.209) [AS174] 0 ms 0 ms 0 ms 4 vl3493.mpd01.dca02.atlas.cogentco.com (154.54.7.230) [AS174] 1 ms te4-1.mpd01.dca02.atlas.cogentco.com (154.54.2.182) [AS174] 25 ms 94 ms 5 vl3496.mpd01.iad01.atlas.cogentco.com (154.54.5.46) [AS174] 1 ms te1-2.ccr02.iad01.atlas.cogentco.com (154.54.7.158) [AS174] 1 ms te2-2.ccr02.iad01.atlas.cogentco.com (154.54.7.162) [AS174] 1 ms 6 gi9-0-0.core01.iad01.atlas.cogentco.com (154.54.3.221) [AS174] 1 ms gi0-0-0.core01.iad01.atlas.cogentco.com (154.54.3.225) [AS174] 1 ms 1 ms 7 sprint.iad01.atlas.cogentco.com (154.54.13.62) [AS174] 1 ms 1 ms 1 ms 8 sl-crs2-rly-0-1-3-0.sprintlink.net (144.232.20.188) [AS1239] 3 ms 4 ms 3 ms 9 sl-crs2-sj-0-0-0-2.sprintlink.net (144.232.8.145) [AS1239] 70 ms 71 ms 70 ms 10 sl-st1-sc-1-1.sprintlink.net (144.232.20.197) [AS1239] 71 ms 71 ms 71 ms 11 sl-rhyth2-158722-0.sprintlink.net (144.228.111.26) [AS1239] 71 ms 71 ms 71 ms 12 208.91.188.68 (208.91.188.68) [] 71 ms 71 ms 71 ms 13 ops1.scc.rnmd.net (208.91.188.136) [] 71 ms 71 ms 71 ms traceroute to ops1.scc.rnmd.net (208.91.188.136), 30 hops max, 40 byte packets 1 lid-br1-g0-2-10.ops.theveniceproject.com (89.251.0.1) [AS42072] 0.428 ms 0.373 ms 0.368 ms 2 gi4-10.ccr01.ams05.atlas.cogentco.com (149.6.128.125) [AS174] 1.474 ms 1.415 ms 1.420 ms 3 te3-4.ccr01.ams03.atlas.cogentco.com (130.117.0.85) [AS174] 1.668 ms 1.734 ms 1.617 ms 4 gi2-0-0.core01.ams03.atlas.cogentco.com (130.117.0.33) [AS174] 1.573 ms 1.620 ms gi10-0-0.core01.ams03.atlas.cogentco.com (130.117.0.237) [AS174] 1.618 ms 5 sprint.ams03.atlas.cogentco.com (130.117.14.122) [AS174] 1.606 ms 1.617 ms 1.569 ms 6 sl-bb21-ams-15-0-0.sprintlink.net (217.149.32.34) [AS1239] 1.673 ms 1.721 ms 1.571 ms 7 sl-bb23-lon-4-0.sprintlink.net (213.206.129.143) [AS1239] 9.562 ms 9.500 ms 9.456 ms 8 sl-bb21-lon-13-0.sprintlink.net (213.206.128.55) [AS1239] 9.660 ms 9.628 ms 9.601 ms 9 * * * 10 * * * HTH Andrew > > On Sep 19, 2008, at 4:27 AM, Craig Holland wrote: > >> Hi, >> >> We are seeing traffic getting dropped between our Cogent and Sprint >> connect DC's. One of them is getting shutdown, so we just have a >> Cogent >> link there :| Anyone seeing anything similar? >> >> From: 91.102.40.18 >> traceroute to ops1.scc.rnmd.net (208.91.188.136), 30 hops max, 38 byte >> packets >> 1 v1-core-sw1 (91.102.40.5) 0.471 ms 0.422 ms 0.431 ms >> 2 ge-0-1-0-pat2 (91.102.40.146) 0.376 ms 0.354 ms 0.335 ms >> 3 fe-1-3-1-501-pat1 (91.102.40.208) 0.376 ms 0.344 ms 0.407 ms >> 4 vl324.mpd01.lon01.atlas.cogentco.com (149.6.147.217) 0.745 ms >> 0.744 ms 0.740 ms >> 5 te3-1.mpd02.lon01.atlas.cogentco.com (130.117.2.26) 0.717 ms >> 39.037 ms te1-8.ccr01.lon01.atlas.cogentco.com (130.117.3.226) 0.565 >> ms >> 6 gi6-0-0.core01.lon01.atlas.cogentco.com (130.117.1.73) 0.592 ms >> 0.450 ms 0.483 ms >> 7 213.206.131.29 (213.206.131.29) 0.581 ms 0.503 ms 0.483 ms >> 8 sl-bb21-lon-3-0.sprintlink.net (213.206.129.152) 1.078 ms 0.905 >> ms >> 0.934 ms >> 9 * >> >>> From 208.91.188.138 >> traceroute to ops2.lnc.rnmd.net (91.102.40.18), 30 hops max, 38 byte >> packets >> 1 v1-core-sw1 (208.91.188.130) 0.600 ms 0.456 ms 2.105 ms >> 2 f0-0-4-0-pat2 (207.0.21.114) 0.416 ms 0.466 ms 0.486 ms >> 3 sl-st1-sc-2-6.sprintlink.net (144.228.111.25) 0.455 ms 0.224 ms >> 0.236 ms >> 4 sl-crs2-sj-0-1-0-3.sprintlink.net (144.232.20.196) 1.482 ms 1.477 >> ms 1.232 ms >> 5 sl-st20-sj-12-0-0.sprintlink.net (144.232.20.63) 2.482 ms 2.472 >> ms >> 2.485 ms >> 6 po5-3.core01.sjc03.atlas.cogentco.com (154.54.13.49) 2.732 ms >> 2.472 ms 2.485 ms >> 7 te3-1.mpd01.sjc03.atlas.cogentco.com (154.54.6.85) 2.705 ms 2.723 >> ms 2.735 ms >> 8 vl3493.ccr02.sjc01.atlas.cogentco.com (154.54.6.109) 3.231 ms >> vl3492.mpd01.sjc01.atlas.cogentco.com (154.54.6.105) 3.227 ms >> vl3491.ccr02.sjc01.atlas.cogentco.com (154.54.6.101) 2.726 ms >> 9 te9-3.mpd01.sfo01.atlas.cogentco.com (154.54.2.53) 3.968 ms 3.722 >> ms te8-3.ccr02.sfo01.atlas.cogentco.com (154.54.2.137) 3.988 ms >> 10 te9-2.ccr02.mci01.atlas.cogentco.com (154.54.24.118) 50.943 ms >> te7-4.mpd01.mci01.atlas.cogentco.com (154.54.24.106) 50.944 ms >> 50.720 >> ms >> 11 te9-3.ccr02.ord01.atlas.cogentco.com (154.54.25.78) 50.669 ms >> 63.423 ms te9-3.mpd01.ord01.atlas.cogentco.com (154.54.25.82) 51.206 >> ms >> 12 te2-1.ccr02.bos01.atlas.cogentco.com (154.54.7.170) 78.172 ms >> te3-3.mpd01.bos01.atlas.cogentco.com (154.54.7.82) 100.666 ms >> te2-1.ccr02.bos01.atlas.cogentco.com (154.54.7.170) 78.176 ms >> 13 * * * >> >> Thanks, >> craig >> >> ________________________ >> Craig Holland >> Rhythm NewMedia >> Sr. Director Operations & Integration >> YIM: cholland >> >> >> > > From cidr-report at potaroo.net Fri Sep 19 07:00:05 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 19 Sep 2008 22:00:05 +1000 (EST) Subject: BGP Update Report Message-ID: <200809191200.m8JC05rK007520@wattle.apnic.net> BGP Update Report Interval: 18-Aug-08 -to- 18-Sep-08 (32 days) Observation Point: BGP Peering with AS2.0 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9583 301731 3.8% 226.5 -- SIFY-AS-IN Sify Limited 2 - AS1803 126042 1.6% 94.9 -- ICMNET-5 - Sprint 3 - AS4538 107539 1.3% 21.4 -- ERX-CERNET-BKB China Education and Research Network Center 4 - AS5691 77600 1.0% 5969.2 -- MITRE-AS-5 - The MITRE Corporation 5 - AS8151 76788 1.0% 31.8 -- Uninet S.A. de C.V. 6 - AS6389 67460 0.8% 15.5 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 7 - AS9051 65154 0.8% 407.2 -- IDM Autonomous System 8 - AS209 51813 0.7% 10.8 -- ASN-QWEST - Qwest 9 - AS14593 50458 0.6% 50458.0 -- BRAND-INSTITUTE - Brand Instiute, Inc. 10 - AS10396 46699 0.6% 667.1 -- COQUI-NET - DATACOM CARIBE, INC. 11 - AS17488 44961 0.6% 30.8 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 12 - AS4184 43385 0.5% 21692.5 -- STORTEK-WHQ - Storage Technology Corporation 13 - AS8866 39604 0.5% 123.0 -- BTC-AS Bulgarian Telecommunication Company Plc. 14 - AS20115 38076 0.5% 21.4 -- CHARTER-NET-HKY-NC - Charter Communications 15 - AS18231 36058 0.5% 146.0 -- EXATT-AS-AP IOL NETCOM LTD 16 - AS7018 35690 0.5% 24.2 -- ATT-INTERNET4 - AT&T WorldNet Services 17 - AS6663 35173 0.4% 286.0 -- EUROWEBRO Euroweb Romania SA 18 - AS9198 34983 0.4% 152.1 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 19 - AS4755 33910 0.4% 19.5 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 20 - AS6458 31107 0.4% 70.2 -- Telgua TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS14593 50458 0.6% 50458.0 -- BRAND-INSTITUTE - Brand Instiute, Inc. 2 - AS4184 43385 0.5% 21692.5 -- STORTEK-WHQ - Storage Technology Corporation 3 - AS8266 9569 0.1% 9569.0 -- NEXUSTEL Nexus Telecommunications 4 - AS29910 8235 0.1% 8235.0 -- IACP - INTL. ASSN OF CHIEF OF POLICEI 5 - AS5691 77600 1.0% 5969.2 -- MITRE-AS-5 - The MITRE Corporation 6 - AS38180 5727 0.1% 5727.0 -- ETPI-IDS-JOLLIBEE-AS-AP 6/Fth floor JOLLIBEE PLAZA, Emerald Ave. Ortigas Center Pasig City. 7 - AS43299 4606 0.1% 4606.0 -- TELECONTACT-AS Telecontact Ltd. 8 - AS4557 7873 0.1% 3936.5 -- EP0-BLK-ASNBLOCK-7 - EP.NET, LLC. 9 - AS23082 18900 0.2% 3780.0 -- MPHI - Michigan Public Health Institute 10 - AS11971 21651 0.3% 3093.0 -- PFIZERNET-GROTON - PFIZER INC. 11 - AS30969 23119 0.3% 2311.9 -- TAN-NET TransAfrica Networks 12 - AS23917 2160 0.0% 2160.0 -- BRIBIE-NET-AS-AP Bribie Island Net Multihomed, Brisbane 13 - AS24491 1774 0.0% 1774.0 -- WORLDWEB-THAILAND-AS-AP Internet Service Provider Thailand 14 - AS44194 1590 0.0% 1590.0 -- FREIFUNK-BERLIN-AS Freifunk Berlin 15 - AS32011 1577 0.0% 1577.0 -- JOHO-NYC - Joho Capital, LLC 16 - AS9747 12268 0.1% 1533.5 -- EZINTERNET-AS-AP EZInternet Pty Ltd 17 - AS25321 1249 0.0% 1249.0 -- G4S-NET GROUP 4 SECURITAS Prague 18 - AS26276 5529 0.1% 1105.8 -- TIMKEN-USA - The Timken Company 19 - AS39843 2156 0.0% 1078.0 -- RATECOM-AS Joint Stock Company "Ratecom" 20 - AS3944 4275 0.1% 1068.8 -- PARTAN-LAB - Partan & Partan TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 192.12.120.0/24 77527 0.9% AS5691 -- MITRE-AS-5 - The MITRE Corporation 2 - 221.134.222.0/24 59162 0.7% AS9583 -- SIFY-AS-IN Sify Limited 3 - 194.126.143.0/24 57735 0.7% AS9051 -- IDM Autonomous System 4 - 210.214.151.0/24 55122 0.6% AS9583 -- SIFY-AS-IN Sify Limited 5 - 12.8.7.0/24 50458 0.6% AS14593 -- BRAND-INSTITUTE - Brand Instiute, Inc. 6 - 210.210.112.0/24 44322 0.5% AS9583 -- SIFY-AS-IN Sify Limited 7 - 221.135.80.0/24 44047 0.5% AS9583 -- SIFY-AS-IN Sify Limited 8 - 221.135.251.0/24 42813 0.5% AS9583 -- SIFY-AS-IN Sify Limited 9 - 83.228.71.0/24 30651 0.4% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 10 - 221.128.192.0/18 27373 0.3% AS18231 -- EXATT-AS-AP IOL NETCOM LTD 11 - 72.50.96.0/20 24360 0.3% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 12 - 199.117.144.0/22 21694 0.2% AS4184 -- STORTEK-WHQ - Storage Technology Corporation 13 - 129.80.0.0/16 21691 0.2% AS4184 -- STORTEK-WHQ - Storage Technology Corporation 14 - 12.18.36.0/24 21381 0.2% AS11971 -- PFIZERNET-GROTON - PFIZER INC. 15 - 196.42.0.0/20 21180 0.2% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 16 - 89.38.98.0/23 18104 0.2% AS6663 -- EUROWEBRO Euroweb Romania SA 17 - 86.105.182.0/24 13985 0.2% AS6663 -- EUROWEBRO Euroweb Romania SA 18 - 195.251.5.0/24 12799 0.1% AS5408 -- GR-NET Greek Research & Technology Network, http://www.grnet.gr 19 - 89.4.131.0/24 12704 0.1% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 20 - 205.162.132.0/23 12495 0.1% AS23541 -- Scarlet B.V. 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 Sep 19 07:00:00 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 19 Sep 2008 22:00:00 +1000 (EST) Subject: The Cidr Report Message-ID: <200809191200.m8JC004o007491@wattle.apnic.net> This report has been generated at Fri Sep 19 21:18:31 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 12-09-08 279371 169113 13-09-08 281264 169195 14-09-08 280983 169796 15-09-08 280912 169979 16-09-08 280891 170665 17-09-08 281142 171487 18-09-08 281677 171559 19-09-08 281956 171946 AS Summary 29399 Number of ASes in routing system 12454 Number of ASes announcing only one prefix 5025 Largest number of prefixes announced by an AS AS4538 : ERX-CERNET-BKB China Education and Research Network Center 88271360 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'). --- 19Sep08 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 281831 171930 109901 39.0% All ASes AS4538 5025 886 4139 82.4% ERX-CERNET-BKB China Education and Research Network Center AS6389 4295 351 3944 91.8% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS209 2946 1334 1612 54.7% ASN-QWEST - Qwest AS4755 1728 303 1425 82.5% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS6298 1981 756 1225 61.8% COX-PHX - Cox Communications Inc. AS8151 1736 584 1152 66.4% Uninet S.A. de C.V. AS17488 1384 286 1098 79.3% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4323 1513 480 1033 68.3% TWTC - tw telecom holdings, inc. AS1785 1656 655 1001 60.4% AS-PAETEC-NET - PaeTec Communications, Inc. AS22773 979 65 914 93.4% CCINET-2 - Cox Communications Inc. AS11492 1217 411 806 66.2% CABLEONE - CABLE ONE AS18566 1049 276 773 73.7% COVAD - Covad Communications Co. AS19262 953 201 752 78.9% VZGNI-TRANSIT - Verizon Internet Services Inc. AS2386 1552 906 646 41.6% INS-AS - AT&T Data Communications Services AS9498 678 70 608 89.7% BBIL-AP BHARTI Airtel Ltd. AS6478 1169 587 582 49.8% ATT-INTERNET3 - AT&T WorldNet Services AS18101 754 192 562 74.5% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS3356 984 463 521 52.9% LEVEL3 Level 3 Communications AS4766 902 408 494 54.8% KIXS-AS-KR Korea Telecom AS4808 629 155 474 75.4% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS17676 524 63 461 88.0% GIGAINFRA BB TECHNOLOGY Corp. AS855 595 143 452 76.0% CANET-ASN-4 - Bell Aliant AS4134 842 390 452 53.7% CHINANET-BACKBONE No.31,Jin-rong Street AS7545 584 140 444 76.0% TPG-INTERNET-AP TPG Internet Pty Ltd AS22047 564 127 437 77.5% VTR BANDA ANCHA S.A. AS9443 522 86 436 83.5% INTERNETPRIMUS-AS-AP Primus Telecommunications AS7029 527 93 434 82.4% WINDSTREAM - Windstream Communications Inc AS24560 584 155 429 73.5% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7018 1418 1000 418 29.5% ATT-INTERNET4 - AT&T WorldNet Services AS4668 683 274 409 59.9% LGNET-AS-KR LG CNS Total 39973 11840 28133 70.4% Top 30 total Possible Bogus Routes 24.75.116.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 24.75.160.0/19 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.245.128.0/17 AS11492 CABLEONE - CABLE ONE 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.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.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 64.188.0.0/16 AS3356 LEVEL3 Level 3 Communications 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.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 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 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 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 94.126.88.0/23 AS12695 DINET-AS Digital Network JSC 94.249.128.0/17 AS12586 ASGHOSTNET +------------------------------- 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 119.31.232.0/21 AS38870 121.50.12.0/24 AS38236 121.50.13.0/24 AS38236 121.50.14.0/24 AS38236 121.50.15.0/24 AS38236 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.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.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.248.0/23 AS680 DFN-IP service G-WiN 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.25.240.0/21 AS3209 Arcor IP-Network 193.25.246.0/24 AS3211 Arcor Data-Network 193.200.114.0/23 AS31530 SERVERCREW-AS Servercrew LTD Autonomes System 193.218.205.224/27 AS41913 COMPUTERLINE Computerline, Schlierbach, Switzerland 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 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 - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 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.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.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.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.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.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.144.160.0/20 AS7296 ALCHEMYNET - Alchemy Communications, 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.220/32 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.241.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 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/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.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 209.74.96.0/20 AS16776 MOVE-CORP - Move Sales, Inc. 209.74.112.0/20 AS16776 MOVE-CORP - Move Sales, Inc. 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.127.124.0/23 AS2828 XO-AS15 - XO Communications 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.210.86.0/24 AS577 BACOM - Bell Canada 216.229.51.0/24 AS15211 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 jbaldwin at antinode.net Fri Sep 19 07:00:58 2008 From: jbaldwin at antinode.net (James Baldwin) Date: Fri, 19 Sep 2008 07:00:58 -0500 Subject: Level(3) Issues Message-ID: <4d668a580809190500k24300274xb3049296ac806860@mail.gmail.com> Is anyone else experiencing increased latency or packet loss through the Level3/Broadwing network? I have seen sporadic packet loss to several locations nationally over the last several hours. From roy at gnomon.org.uk Fri Sep 19 08:14:45 2008 From: roy at gnomon.org.uk (Roy Badami) Date: Fri, 19 Sep 2008 14:14:45 +0100 Subject: Sprint/Cogent Peering Issue? In-Reply-To: <18643.30613.428941.158081@giles.gnomon.org.uk> References: <3FEEC5BE16966148B912DEB0FF34C81C70FC63@BE09.exg4.exghost.com> <18643.30613.428941.158081@giles.gnomon.org.uk> Message-ID: <18643.42437.396814.367807@giles.gnomon.org.uk> FWIW, the Sprint routing issues we were seeing seem to have been resolved now, AFAICS. -roy From pstewart at nexicomgroup.net Fri Sep 19 08:16:40 2008 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Fri, 19 Sep 2008 09:16:40 -0400 Subject: Level(3) Issues In-Reply-To: <4d668a580809190500k24300274xb3049296ac806860@mail.gmail.com> References: <4d668a580809190500k24300274xb3049296ac806860@mail.gmail.com> Message-ID: <89D27DE3375BB6428DDCC2927489826A0198D6AC@nexus.nexicomgroup.net> Can you post a couple of IP's ? We're out of Level(3) Detroit node and don't see anything towards Disney.com etc.... Paul -----Original Message----- From: James Baldwin [mailto:jbaldwin at antinode.net] Sent: Friday, September 19, 2008 8:01 AM To: nanog at nanog.org Subject: Level(3) Issues Is anyone else experiencing increased latency or packet loss through the Level3/Broadwing network? I have seen sporadic packet loss to several locations nationally over the last several hours. ---------------------------------------------------------------------------- "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 robert at ufl.edu Fri Sep 19 08:21:01 2008 From: robert at ufl.edu (Robert D. Scott) Date: Fri, 19 Sep 2008 09:21:01 -0400 Subject: Level(3) Issues In-Reply-To: <89D27DE3375BB6428DDCC2927489826A0198D6AC@nexus.nexicomgroup.net> References: <4d668a580809190500k24300274xb3049296ac806860@mail.gmail.com> <89D27DE3375BB6428DDCC2927489826A0198D6AC@nexus.nexicomgroup.net> Message-ID: <028d01c91a5a$8fc3ea50$af4bbef0$@edu> No issues Tampa to San Fran. 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: Paul Stewart [mailto:pstewart at nexicomgroup.net] Sent: Friday, September 19, 2008 9:17 AM To: James Baldwin; nanog at nanog.org Subject: RE: Level(3) Issues Can you post a couple of IP's ? We're out of Level(3) Detroit node and don't see anything towards Disney.com etc.... Paul -----Original Message----- From: James Baldwin [mailto:jbaldwin at antinode.net] Sent: Friday, September 19, 2008 8:01 AM To: nanog at nanog.org Subject: Level(3) Issues Is anyone else experiencing increased latency or packet loss through the Level3/Broadwing network? I have seen sporadic packet loss to several locations nationally over the last several hours. ---------------------------------------------------------------------------- "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 marks at bit.nl Fri Sep 19 08:31:53 2008 From: marks at bit.nl (Mark Schouten) Date: Fri, 19 Sep 2008 15:31:53 +0200 Subject: virbl.bit.nl, A list of virussending IP's Message-ID: <1221831113.21191.100.camel@highway> Hi All, Some of you might have heard about or suffered a listing on virbl.bit.nl. Virbl is a dns-list with IP's of which we (BIT) or one of the contributors [1] have received a email with a virus. We will list an IP after it has sent two virus-emails to one of our sources. We will remember that you sent those emails for seven days. IP's will only be listed as long as the last time we 'saw' the IP sending virusses is less than 24 hours and the total sent emails is greater than two, in the last seven days. The goal is to stop infected machines from sending virusses, and stop relaying-servers from forwarding, bouncing and otherwise deliver virusses. It does definitely help in preventing the use of useless cou cycles for scanning mail in your mailsetup. AS Administrators can login at [2]. A password will be emailed to a address you select. We look for addresses in the whois-info for your AS. You can see evidence, suspend hosts from the list and see stats about your AS. We are working on notifications, which will also be configurable in the login-interface. We currently use dnswl and the nlwhitelist (a list with the relay-servers for Dutch ISP's) as a exclude list. If anyone knows another trustworthy whitelist with relayservers from ISP's, please let me know so we can think about using that too. Also, if you're interested in contributing to Virbl, please email me off list. We prefer consumer ISP's, with some million messages per day. If you're using MailScanner or Amavisd-new, that would be great. Offcourse, the use of Virbl is free. See [3] on howto use it. Thanks, Links to http://virbl.bit.nl/ [1] http://virbl.bit.nl/contributors.php [2] https://virbl.bit.nl/login/ [3] http://virbl.bit.nl/usage.php -- Mark Schouten, Unix/NOC-engineer BIT BV | info at bit.nl | +31 318 648688 MS8714-RIPE | B1FD 8E60 A184 F89A 450D A128 049B 1B19 9AD6 177FF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From patrick at zill.net Fri Sep 19 11:49:51 2008 From: patrick at zill.net (Patrick Giagnocavo) Date: Fri, 19 Sep 2008 12:49:51 -0400 Subject: Level3 must have changed a lot on East Coast...any info? Message-ID: <48D3D82F.9020207@zill.net> Does anyone have more info as to what Level3 changed last night during their maintenace window? Also I am going through either WashDC or Atlanta it seems, on most traceroutes. Here is a weird traceroute from this morning (note the first 4 traces): traceroute cwlabs.com (used as an example) traceroute to cwlabs.com (208.113.235.175), 30 hops max, 40 byte packets 1 ae-2.ebr3.Atlanta2.Level3.net (4.69.132.85) 142.747 ms 105.051 ms 106.480 ms 2 ae-2.ebr3.Atlanta2.Level3.net (4.69.132.85) 54.189 ms 52.121 ms 55.308 ms 3 ae-2.ebr3.Atlanta2.Level3.net (4.69.132.85) 52.709 ms 52.413 ms 53.878 ms 4 ae-2.ebr3.Atlanta2.Level3.net (4.69.132.85) 54.447 ms 55.481 ms 50.730 ms 5 ae-2.ebr3.Atlanta2.Level3.net (4.69.132.85) 55.489 ms 50.655 ms 54.116 ms 6 ae-7.ebr3.Dallas1.Level3.net (4.69.134.21) 75.441 ms 73.117 ms 69.460 ms 7 ae-3.ebr2.LosAngeles1.Level3.net (4.69.132.77) 99.071 ms 102.945 ms 109.537 ms 8 ae-82-82.csw3.LosAngeles1.Level3.net (4.69.137.26) 109.883 ms 106.218 ms 108.255 ms 9 ae-31-89.car1.LosAngeles1.Level3.net (4.68.20.131) 98.933 ms 100.706 ms 97.177 ms 10 INTERNAP-NE.car1.LosAngeles1.Level3.net (4.71.140.54) 97.548 ms 98.300 ms 97.674 ms 11 border20.po2-20g-bbnet2.lax.pnap.net (216.52.255.101) 102.012 ms 101.854 ms 98.889 ms 12 newdream-8.border20.lax.pnap.net (216.52.220.146) 97.053 ms 98.325 ms 97.547 ms 13 ip-66-33-201-66.dreamhost.com (66.33.201.66) 98.530 ms 101.100 ms 98.141 ms 14 basic-dap.marvin.dreamhost.com (208.113.235.175) 97.895 ms 97.204 ms 97.296 ms --Patrick From jra at baylink.com Fri Sep 19 12:10:21 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Fri, 19 Sep 2008 13:10:21 -0400 (EDT) Subject: Paging a RIM/Blackberry email staffer In-Reply-To: <33051837.251221844183835.JavaMail.root@benjamin.vicimarketing.com> Message-ID: <26654547.271221844221600.JavaMail.root@benjamin.vicimarketing.com> Since postmaster@ is bouncing... (If you are not a RIM employee, you can stop reading now) Due to yahoo's DNS servers deciding to say, this morning, that my MX records point to email.vicimarketing.com.115, in that popular new ".115" gTLD... I moved the zone service inhouse. In the process, the email gateway recursors at Blackberry appear to have negative cached that my domain doesn't exist, and carbon copies to *all* of my various BIS BBs are bouncing "55 5.1.8 domain of sender address "jra at vicimarketing.com" does not exist". Anyone listening who can restart those recursive servers? 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 cscora at apnic.net Fri Sep 19 13:09:02 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 20 Sep 2008 04:09:02 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200809191809.m8JI92X3032458@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 20 Sep, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 269427 Prefixes after maximum aggregation: 129901 Deaggregation factor: 2.07 Unique aggregates announced to Internet: 131012 Total ASes present in the Internet Routing Table: 29274 Prefixes per ASN: 9.20 Origin-only ASes present in the Internet Routing Table: 25443 Origin ASes announcing only one prefix: 12385 Transit ASes present in the Internet Routing Table: 3831 Transit-only ASes present in the Internet Routing Table: 82 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 26 Max AS path prepend of ASN ( 3816) 15 Prefixes from unregistered ASNs in the Routing Table: 558 Unregistered ASNs in the Routing Table: 209 Number of 32-bit ASNs allocated by the RIRs: 60 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: 755 Number of addresses announced to Internet: 1921880352 Equivalent to 114 /8s, 141 /16s and 145 /24s Percentage of available address space announced: 51.9 Percentage of allocated address space announced: 63.0 Percentage of available address space allocated: 82.3 Percentage of address space in use by end-sites: 73.6 Total number of prefixes smaller than registry allocations: 132145 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 62233 Total APNIC prefixes after maximum aggregation: 22899 APNIC Deaggregation factor: 2.72 Prefixes being announced from the APNIC address blocks: 59152 Unique aggregates announced from the APNIC address blocks: 26429 APNIC Region origin ASes present in the Internet Routing Table: 3387 APNIC Prefixes per ASN: 17.46 APNIC Region origin ASes announcing only one prefix: 905 APNIC Region transit ASes present in the Internet Routing Table: 537 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 18 Number of APNIC addresses announced to Internet: 376338720 Equivalent to 22 /8s, 110 /16s and 121 /24s Percentage of available APNIC address space announced: 80.1 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: 122394 Total ARIN prefixes after maximum aggregation: 64619 ARIN Deaggregation factor: 1.89 Prefixes being announced from the ARIN address blocks: 91649 Unique aggregates announced from the ARIN address blocks: 35095 ARIN Region origin ASes present in the Internet Routing Table: 12444 ARIN Prefixes per ASN: 7.36 ARIN Region origin ASes announcing only one prefix: 4804 ARIN Region transit ASes present in the Internet Routing Table: 1200 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 16 Number of ARIN addresses announced to Internet: 364358112 Equivalent to 21 /8s, 183 /16s and 169 /24s Percentage of available ARIN address space announced: 74.9 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: 58324 Total RIPE prefixes after maximum aggregation: 35258 RIPE Deaggregation factor: 1.65 Prefixes being announced from the RIPE address blocks: 53463 Unique aggregates announced from the RIPE address blocks: 35860 RIPE Region origin ASes present in the Internet Routing Table: 11903 RIPE Prefixes per ASN: 4.49 RIPE Region origin ASes announcing only one prefix: 6267 RIPE Region transit ASes present in the Internet Routing Table: 1815 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 26 Number of RIPE addresses announced to Internet: 372326720 Equivalent to 22 /8s, 49 /16s and 65 /24s Percentage of available RIPE address space announced: 85.4 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-49151 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: 21824 Total LACNIC prefixes after maximum aggregation: 5394 LACNIC Deaggregation factor: 4.05 Prefixes being announced from the LACNIC address blocks: 20024 Unique aggregates announced from the LACNIC address blocks: 11116 LACNIC Region origin ASes present in the Internet Routing Table: 998 LACNIC Prefixes per ASN: 20.06 LACNIC Region origin ASes announcing only one prefix: 329 LACNIC Region transit ASes present in the Internet Routing Table: 172 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 21 Number of LACNIC addresses announced to Internet: 56720896 Equivalent to 3 /8s, 97 /16s and 126 /24s Percentage of available LACNIC address space announced: 56.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: 4094 Total AfriNIC prefixes after maximum aggregation: 1267 AfriNIC Deaggregation factor: 3.23 Prefixes being announced from the AfriNIC address blocks: 4413 Unique aggregates announced from the AfriNIC address blocks: 2040 AfriNIC Region origin ASes present in the Internet Routing Table: 257 AfriNIC Prefixes per ASN: 17.17 AfriNIC Region origin ASes announcing only one prefix: 80 AfriNIC Region transit ASes present in the Internet Routing Table: 54 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 16 Number of AfriNIC addresses announced to Internet: 12729088 Equivalent to 0 /8s, 194 /16s and 59 /24s Percentage of available AfriNIC address space announced: 37.9 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 1721 538 181 Videsh Sanchar Nigam Ltd. Aut 17488 1384 94 101 Hathway IP Over Cable Interne 9583 1107 86 472 Sify Limited 4766 875 6407 359 Korea Telecom (KIX) 4134 842 13651 345 CHINANET-BACKBONE 23577 819 35 695 Korea Telecom (ATM-MPLS) 18101 766 152 51 Reliance Infocom Ltd Internet 4780 715 353 61 Digital United Inc. 9498 677 291 54 BHARTI BT INTERNET LTD. 4808 629 1156 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 4292 3416 339 bellsouth.net, inc. 209 2927 4001 618 Qwest 6298 1980 316 736 Cox Communicatons 20115 1689 1428 713 Charter Communications 1785 1656 710 156 AppliedTheory Corporation 2386 1550 691 892 AT&T Data Communications Serv 4323 1516 1065 368 Time Warner Telecom 7018 1402 5802 973 AT&T WorldNet Services 11492 1217 152 11 Cable One 6478 1169 241 185 AT&T Worldnet Services 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 421 1777 378 TDC Tele Danmark 3301 332 1444 303 TeliaNet Sweden 30890 329 87 175 SC Kappa Invexim SRL 3215 327 2756 106 France Telecom Transpac 3320 324 7063 273 Deutsche Telekom AG 8866 319 77 21 Bulgarian Telecommunication C 8452 316 188 11 TEDATA 5462 296 794 27 Telewest Broadband 8551 287 270 37 Bezeq International 680 275 2047 265 DFN-IP service G-WiN 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 1739 2877 226 UniNet S.A. de C.V. 11830 668 299 9 Instituto Costarricense de El 22047 564 270 14 VTR PUNTO NET S.A. 7303 490 241 70 Telecom Argentina Stet-France 10620 429 105 60 TVCABLE BOGOTA 16814 426 27 10 NSS, S.A. 6471 420 85 48 ENTEL CHILE S.A. 11172 409 118 72 Servicios Alestra S.A de C.V 28573 351 443 28 NET Servicos de Comunicao S.A 14117 345 23 9 Telefonica del Sur S.A. 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 516 67 32 LINKdotNET AS number 20858 403 34 3 EgyNet 3741 265 855 223 The Internet Solution 2018 232 215 139 Tertiary Education Network 6713 143 135 11 Itissalat Al-MAGHRIB 33783 137 10 13 EEPAD TISP TELECOM & INTERNET 5536 120 8 17 Internet Egypt Network 5713 118 555 68 Telkom SA Ltd 33776 115 6 3 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 4292 3416 339 bellsouth.net, inc. 209 2927 4001 618 Qwest 6298 1980 316 736 Cox Communicatons 8151 1739 2877 226 UniNet S.A. de C.V. 4755 1721 538 181 Videsh Sanchar Nigam Ltd. Aut 20115 1689 1428 713 Charter Communications 1785 1656 710 156 AppliedTheory Corporation 2386 1550 691 892 AT&T Data Communications Serv 4323 1516 1065 368 Time Warner Telecom 7018 1402 5802 973 AT&T WorldNet Services Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2927 2309 Qwest 4755 1721 1540 Videsh Sanchar Nigam Ltd. Aut 8151 1739 1513 UniNet S.A. de C.V. 1785 1656 1500 AppliedTheory Corporation 17488 1384 1283 Hathway IP Over Cable Interne 6298 1980 1244 Cox Communicatons 11492 1217 1206 Cable One 4323 1516 1148 Time Warner Telecom 18566 1049 1039 Covad Communications 6478 1169 984 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 7018 AT&T WorldNet Servic 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 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.75.160.0/19 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 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio 63.143.71.0/24 701 UUNET Technologies, Inc. 63.143.115.0/24 701 UUNET Technologies, Inc. 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:17 /11:45 /12:147 /13:294 /14:529 /15:1072 /16:10090 /17:4390 /18:7733 /19:16281 /20:19082 /21:18612 /22:23366 /23:24446 /24:140670 /25:791 /26:968 /27:760 /28:89 /29:9 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2846 4292 bellsouth.net, inc. 6298 1955 1980 Cox Communicatons 209 1690 2927 Qwest 2386 1231 1550 AT&T Data Communications Serv 11492 1193 1217 Cable One 17488 1191 1384 Hathway IP Over Cable Interne 1785 1125 1656 AppliedTheory Corporation 6478 1062 1169 AT&T Worldnet Services 4755 1057 1721 Videsh Sanchar Nigam Ltd. Aut 18566 1030 1049 Covad Communications Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:8 8:139 12:2145 13:2 15:20 16:3 17:5 18:13 20:35 24:1087 32:59 38:494 40:91 41:723 43:1 44:2 47:12 52:3 55:3 56:3 57:26 58:527 59:520 60:451 61:950 62:1224 63:2033 64:3215 65:2381 66:3478 67:1243 68:780 69:2308 70:848 71:171 72:2026 73:7 74:1183 75:166 76:265 77:780 78:831 79:256 80:948 81:852 82:584 83:372 84:577 85:1018 86:399 87:713 88:336 89:1354 90:21 91:1497 92:264 93:836 94:147 96:65 97:80 98:321 99:8 114:105 115:47 116:987 117:365 118:229 119:500 120:86 121:593 122:853 123:443 124:857 125:1194 128:357 129:201 130:134 131:411 132:70 133:9 134:178 135:32 136:223 137:96 138:142 139:92 140:503 141:102 142:408 143:300 144:325 145:51 146:370 147:156 148:516 149:209 150:128 151:181 152:147 153:136 154:10 155:281 156:175 157:299 158:170 159:300 160:275 161:137 162:255 163:150 164:515 165:499 166:367 167:331 168:631 169:143 170:444 171:33 172:10 173:33 186:1 187:10 188:1 189:608 190:2262 192:5751 193:4144 194:3259 195:2579 196:996 198:3724 199:3297 200:5566 201:1505 202:7851 203:8093 204:3946 205:2136 206:2356 207:2731 208:3600 209:3411 210:2604 211:1088 212:1453 213:1622 214:178 215:50 216:4357 217:1213 218:345 219:437 220:1064 221:415 222:314 End of report From surfer at mauigateway.com Fri Sep 19 13:21:31 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 19 Sep 2008 11:21:31 -0700 Subject: Anyone have experience with Alcatel 9500MXC? Message-ID: <20080919112131.79039F51@resin15.mta.everyone.net> --- tom at snnap.net wrote: From: "Tom Storey" I have several of these units deployed, they are all running fine, but I am looking for information about them, specifically SNMP related. Our Alcatel contacts have given us a collection of MIBs, from which I cant really get anything useful out of the radios. Other than that they dont seem too hell bent on providing much further help on this subject. Hoping someone else on here might have experience with these units and can share some information about how to get useful information out of them via SNMP, like traffic and error counters, signal parameters, alarm status, etc. ------------------------------------------ You might try over on alcatel-nsp as well. scott From cscora at apnic.net Fri Sep 19 13:09:02 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 20 Sep 2008 04:09:02 +1000 (EST) Subject: [SANOG] Weekly Routing Table Report Message-ID: <200809191809.m8JI92X3032458@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 20 Sep, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 269427 Prefixes after maximum aggregation: 129901 Deaggregation factor: 2.07 Unique aggregates announced to Internet: 131012 Total ASes present in the Internet Routing Table: 29274 Prefixes per ASN: 9.20 Origin-only ASes present in the Internet Routing Table: 25443 Origin ASes announcing only one prefix: 12385 Transit ASes present in the Internet Routing Table: 3831 Transit-only ASes present in the Internet Routing Table: 82 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 26 Max AS path prepend of ASN ( 3816) 15 Prefixes from unregistered ASNs in the Routing Table: 558 Unregistered ASNs in the Routing Table: 209 Number of 32-bit ASNs allocated by the RIRs: 60 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: 755 Number of addresses announced to Internet: 1921880352 Equivalent to 114 /8s, 141 /16s and 145 /24s Percentage of available address space announced: 51.9 Percentage of allocated address space announced: 63.0 Percentage of available address space allocated: 82.3 Percentage of address space in use by end-sites: 73.6 Total number of prefixes smaller than registry allocations: 132145 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 62233 Total APNIC prefixes after maximum aggregation: 22899 APNIC Deaggregation factor: 2.72 Prefixes being announced from the APNIC address blocks: 59152 Unique aggregates announced from the APNIC address blocks: 26429 APNIC Region origin ASes present in the Internet Routing Table: 3387 APNIC Prefixes per ASN: 17.46 APNIC Region origin ASes announcing only one prefix: 905 APNIC Region transit ASes present in the Internet Routing Table: 537 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 18 Number of APNIC addresses announced to Internet: 376338720 Equivalent to 22 /8s, 110 /16s and 121 /24s Percentage of available APNIC address space announced: 80.1 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: 122394 Total ARIN prefixes after maximum aggregation: 64619 ARIN Deaggregation factor: 1.89 Prefixes being announced from the ARIN address blocks: 91649 Unique aggregates announced from the ARIN address blocks: 35095 ARIN Region origin ASes present in the Internet Routing Table: 12444 ARIN Prefixes per ASN: 7.36 ARIN Region origin ASes announcing only one prefix: 4804 ARIN Region transit ASes present in the Internet Routing Table: 1200 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 16 Number of ARIN addresses announced to Internet: 364358112 Equivalent to 21 /8s, 183 /16s and 169 /24s Percentage of available ARIN address space announced: 74.9 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: 58324 Total RIPE prefixes after maximum aggregation: 35258 RIPE Deaggregation factor: 1.65 Prefixes being announced from the RIPE address blocks: 53463 Unique aggregates announced from the RIPE address blocks: 35860 RIPE Region origin ASes present in the Internet Routing Table: 11903 RIPE Prefixes per ASN: 4.49 RIPE Region origin ASes announcing only one prefix: 6267 RIPE Region transit ASes present in the Internet Routing Table: 1815 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 26 Number of RIPE addresses announced to Internet: 372326720 Equivalent to 22 /8s, 49 /16s and 65 /24s Percentage of available RIPE address space announced: 85.4 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-49151 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: 21824 Total LACNIC prefixes after maximum aggregation: 5394 LACNIC Deaggregation factor: 4.05 Prefixes being announced from the LACNIC address blocks: 20024 Unique aggregates announced from the LACNIC address blocks: 11116 LACNIC Region origin ASes present in the Internet Routing Table: 998 LACNIC Prefixes per ASN: 20.06 LACNIC Region origin ASes announcing only one prefix: 329 LACNIC Region transit ASes present in the Internet Routing Table: 172 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 21 Number of LACNIC addresses announced to Internet: 56720896 Equivalent to 3 /8s, 97 /16s and 126 /24s Percentage of available LACNIC address space announced: 56.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: 4094 Total AfriNIC prefixes after maximum aggregation: 1267 AfriNIC Deaggregation factor: 3.23 Prefixes being announced from the AfriNIC address blocks: 4413 Unique aggregates announced from the AfriNIC address blocks: 2040 AfriNIC Region origin ASes present in the Internet Routing Table: 257 AfriNIC Prefixes per ASN: 17.17 AfriNIC Region origin ASes announcing only one prefix: 80 AfriNIC Region transit ASes present in the Internet Routing Table: 54 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 16 Number of AfriNIC addresses announced to Internet: 12729088 Equivalent to 0 /8s, 194 /16s and 59 /24s Percentage of available AfriNIC address space announced: 37.9 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 1721 538 181 Videsh Sanchar Nigam Ltd. Aut 17488 1384 94 101 Hathway IP Over Cable Interne 9583 1107 86 472 Sify Limited 4766 875 6407 359 Korea Telecom (KIX) 4134 842 13651 345 CHINANET-BACKBONE 23577 819 35 695 Korea Telecom (ATM-MPLS) 18101 766 152 51 Reliance Infocom Ltd Internet 4780 715 353 61 Digital United Inc. 9498 677 291 54 BHARTI BT INTERNET LTD. 4808 629 1156 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 4292 3416 339 bellsouth.net, inc. 209 2927 4001 618 Qwest 6298 1980 316 736 Cox Communicatons 20115 1689 1428 713 Charter Communications 1785 1656 710 156 AppliedTheory Corporation 2386 1550 691 892 AT&T Data Communications Serv 4323 1516 1065 368 Time Warner Telecom 7018 1402 5802 973 AT&T WorldNet Services 11492 1217 152 11 Cable One 6478 1169 241 185 AT&T Worldnet Services 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 421 1777 378 TDC Tele Danmark 3301 332 1444 303 TeliaNet Sweden 30890 329 87 175 SC Kappa Invexim SRL 3215 327 2756 106 France Telecom Transpac 3320 324 7063 273 Deutsche Telekom AG 8866 319 77 21 Bulgarian Telecommunication C 8452 316 188 11 TEDATA 5462 296 794 27 Telewest Broadband 8551 287 270 37 Bezeq International 680 275 2047 265 DFN-IP service G-WiN 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 1739 2877 226 UniNet S.A. de C.V. 11830 668 299 9 Instituto Costarricense de El 22047 564 270 14 VTR PUNTO NET S.A. 7303 490 241 70 Telecom Argentina Stet-France 10620 429 105 60 TVCABLE BOGOTA 16814 426 27 10 NSS, S.A. 6471 420 85 48 ENTEL CHILE S.A. 11172 409 118 72 Servicios Alestra S.A de C.V 28573 351 443 28 NET Servicos de Comunicao S.A 14117 345 23 9 Telefonica del Sur S.A. 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 516 67 32 LINKdotNET AS number 20858 403 34 3 EgyNet 3741 265 855 223 The Internet Solution 2018 232 215 139 Tertiary Education Network 6713 143 135 11 Itissalat Al-MAGHRIB 33783 137 10 13 EEPAD TISP TELECOM & INTERNET 5536 120 8 17 Internet Egypt Network 5713 118 555 68 Telkom SA Ltd 33776 115 6 3 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 4292 3416 339 bellsouth.net, inc. 209 2927 4001 618 Qwest 6298 1980 316 736 Cox Communicatons 8151 1739 2877 226 UniNet S.A. de C.V. 4755 1721 538 181 Videsh Sanchar Nigam Ltd. Aut 20115 1689 1428 713 Charter Communications 1785 1656 710 156 AppliedTheory Corporation 2386 1550 691 892 AT&T Data Communications Serv 4323 1516 1065 368 Time Warner Telecom 7018 1402 5802 973 AT&T WorldNet Services Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2927 2309 Qwest 4755 1721 1540 Videsh Sanchar Nigam Ltd. Aut 8151 1739 1513 UniNet S.A. de C.V. 1785 1656 1500 AppliedTheory Corporation 17488 1384 1283 Hathway IP Over Cable Interne 6298 1980 1244 Cox Communicatons 11492 1217 1206 Cable One 4323 1516 1148 Time Warner Telecom 18566 1049 1039 Covad Communications 6478 1169 984 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 7018 AT&T WorldNet Servic 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 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.75.160.0/19 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 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio 63.143.71.0/24 701 UUNET Technologies, Inc. 63.143.115.0/24 701 UUNET Technologies, Inc. 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:17 /11:45 /12:147 /13:294 /14:529 /15:1072 /16:10090 /17:4390 /18:7733 /19:16281 /20:19082 /21:18612 /22:23366 /23:24446 /24:140670 /25:791 /26:968 /27:760 /28:89 /29:9 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2846 4292 bellsouth.net, inc. 6298 1955 1980 Cox Communicatons 209 1690 2927 Qwest 2386 1231 1550 AT&T Data Communications Serv 11492 1193 1217 Cable One 17488 1191 1384 Hathway IP Over Cable Interne 1785 1125 1656 AppliedTheory Corporation 6478 1062 1169 AT&T Worldnet Services 4755 1057 1721 Videsh Sanchar Nigam Ltd. Aut 18566 1030 1049 Covad Communications Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:8 8:139 12:2145 13:2 15:20 16:3 17:5 18:13 20:35 24:1087 32:59 38:494 40:91 41:723 43:1 44:2 47:12 52:3 55:3 56:3 57:26 58:527 59:520 60:451 61:950 62:1224 63:2033 64:3215 65:2381 66:3478 67:1243 68:780 69:2308 70:848 71:171 72:2026 73:7 74:1183 75:166 76:265 77:780 78:831 79:256 80:948 81:852 82:584 83:372 84:577 85:1018 86:399 87:713 88:336 89:1354 90:21 91:1497 92:264 93:836 94:147 96:65 97:80 98:321 99:8 114:105 115:47 116:987 117:365 118:229 119:500 120:86 121:593 122:853 123:443 124:857 125:1194 128:357 129:201 130:134 131:411 132:70 133:9 134:178 135:32 136:223 137:96 138:142 139:92 140:503 141:102 142:408 143:300 144:325 145:51 146:370 147:156 148:516 149:209 150:128 151:181 152:147 153:136 154:10 155:281 156:175 157:299 158:170 159:300 160:275 161:137 162:255 163:150 164:515 165:499 166:367 167:331 168:631 169:143 170:444 171:33 172:10 173:33 186:1 187:10 188:1 189:608 190:2262 192:5751 193:4144 194:3259 195:2579 196:996 198:3724 199:3297 200:5566 201:1505 202:7851 203:8093 204:3946 205:2136 206:2356 207:2731 208:3600 209:3411 210:2604 211:1088 212:1453 213:1622 214:178 215:50 216:4357 217:1213 218:345 219:437 220:1064 221:415 222:314 End of report -- This is the SANOG (http://www.sanog.org/) mailing list. From cscora at apnic.net Fri Sep 19 13:09:02 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 20 Sep 2008 04:09:02 +1000 (EST) Subject: [SANOG] Weekly Routing Table Report Message-ID: <200809191809.m8JI92X3032458@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 20 Sep, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 269427 Prefixes after maximum aggregation: 129901 Deaggregation factor: 2.07 Unique aggregates announced to Internet: 131012 Total ASes present in the Internet Routing Table: 29274 Prefixes per ASN: 9.20 Origin-only ASes present in the Internet Routing Table: 25443 Origin ASes announcing only one prefix: 12385 Transit ASes present in the Internet Routing Table: 3831 Transit-only ASes present in the Internet Routing Table: 82 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 26 Max AS path prepend of ASN ( 3816) 15 Prefixes from unregistered ASNs in the Routing Table: 558 Unregistered ASNs in the Routing Table: 209 Number of 32-bit ASNs allocated by the RIRs: 60 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: 755 Number of addresses announced to Internet: 1921880352 Equivalent to 114 /8s, 141 /16s and 145 /24s Percentage of available address space announced: 51.9 Percentage of allocated address space announced: 63.0 Percentage of available address space allocated: 82.3 Percentage of address space in use by end-sites: 73.6 Total number of prefixes smaller than registry allocations: 132145 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 62233 Total APNIC prefixes after maximum aggregation: 22899 APNIC Deaggregation factor: 2.72 Prefixes being announced from the APNIC address blocks: 59152 Unique aggregates announced from the APNIC address blocks: 26429 APNIC Region origin ASes present in the Internet Routing Table: 3387 APNIC Prefixes per ASN: 17.46 APNIC Region origin ASes announcing only one prefix: 905 APNIC Region transit ASes present in the Internet Routing Table: 537 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 18 Number of APNIC addresses announced to Internet: 376338720 Equivalent to 22 /8s, 110 /16s and 121 /24s Percentage of available APNIC address space announced: 80.1 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: 122394 Total ARIN prefixes after maximum aggregation: 64619 ARIN Deaggregation factor: 1.89 Prefixes being announced from the ARIN address blocks: 91649 Unique aggregates announced from the ARIN address blocks: 35095 ARIN Region origin ASes present in the Internet Routing Table: 12444 ARIN Prefixes per ASN: 7.36 ARIN Region origin ASes announcing only one prefix: 4804 ARIN Region transit ASes present in the Internet Routing Table: 1200 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 16 Number of ARIN addresses announced to Internet: 364358112 Equivalent to 21 /8s, 183 /16s and 169 /24s Percentage of available ARIN address space announced: 74.9 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: 58324 Total RIPE prefixes after maximum aggregation: 35258 RIPE Deaggregation factor: 1.65 Prefixes being announced from the RIPE address blocks: 53463 Unique aggregates announced from the RIPE address blocks: 35860 RIPE Region origin ASes present in the Internet Routing Table: 11903 RIPE Prefixes per ASN: 4.49 RIPE Region origin ASes announcing only one prefix: 6267 RIPE Region transit ASes present in the Internet Routing Table: 1815 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 26 Number of RIPE addresses announced to Internet: 372326720 Equivalent to 22 /8s, 49 /16s and 65 /24s Percentage of available RIPE address space announced: 85.4 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-49151 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: 21824 Total LACNIC prefixes after maximum aggregation: 5394 LACNIC Deaggregation factor: 4.05 Prefixes being announced from the LACNIC address blocks: 20024 Unique aggregates announced from the LACNIC address blocks: 11116 LACNIC Region origin ASes present in the Internet Routing Table: 998 LACNIC Prefixes per ASN: 20.06 LACNIC Region origin ASes announcing only one prefix: 329 LACNIC Region transit ASes present in the Internet Routing Table: 172 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 21 Number of LACNIC addresses announced to Internet: 56720896 Equivalent to 3 /8s, 97 /16s and 126 /24s Percentage of available LACNIC address space announced: 56.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: 4094 Total AfriNIC prefixes after maximum aggregation: 1267 AfriNIC Deaggregation factor: 3.23 Prefixes being announced from the AfriNIC address blocks: 4413 Unique aggregates announced from the AfriNIC address blocks: 2040 AfriNIC Region origin ASes present in the Internet Routing Table: 257 AfriNIC Prefixes per ASN: 17.17 AfriNIC Region origin ASes announcing only one prefix: 80 AfriNIC Region transit ASes present in the Internet Routing Table: 54 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 16 Number of AfriNIC addresses announced to Internet: 12729088 Equivalent to 0 /8s, 194 /16s and 59 /24s Percentage of available AfriNIC address space announced: 37.9 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 1721 538 181 Videsh Sanchar Nigam Ltd. Aut 17488 1384 94 101 Hathway IP Over Cable Interne 9583 1107 86 472 Sify Limited 4766 875 6407 359 Korea Telecom (KIX) 4134 842 13651 345 CHINANET-BACKBONE 23577 819 35 695 Korea Telecom (ATM-MPLS) 18101 766 152 51 Reliance Infocom Ltd Internet 4780 715 353 61 Digital United Inc. 9498 677 291 54 BHARTI BT INTERNET LTD. 4808 629 1156 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 4292 3416 339 bellsouth.net, inc. 209 2927 4001 618 Qwest 6298 1980 316 736 Cox Communicatons 20115 1689 1428 713 Charter Communications 1785 1656 710 156 AppliedTheory Corporation 2386 1550 691 892 AT&T Data Communications Serv 4323 1516 1065 368 Time Warner Telecom 7018 1402 5802 973 AT&T WorldNet Services 11492 1217 152 11 Cable One 6478 1169 241 185 AT&T Worldnet Services 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 421 1777 378 TDC Tele Danmark 3301 332 1444 303 TeliaNet Sweden 30890 329 87 175 SC Kappa Invexim SRL 3215 327 2756 106 France Telecom Transpac 3320 324 7063 273 Deutsche Telekom AG 8866 319 77 21 Bulgarian Telecommunication C 8452 316 188 11 TEDATA 5462 296 794 27 Telewest Broadband 8551 287 270 37 Bezeq International 680 275 2047 265 DFN-IP service G-WiN 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 1739 2877 226 UniNet S.A. de C.V. 11830 668 299 9 Instituto Costarricense de El 22047 564 270 14 VTR PUNTO NET S.A. 7303 490 241 70 Telecom Argentina Stet-France 10620 429 105 60 TVCABLE BOGOTA 16814 426 27 10 NSS, S.A. 6471 420 85 48 ENTEL CHILE S.A. 11172 409 118 72 Servicios Alestra S.A de C.V 28573 351 443 28 NET Servicos de Comunicao S.A 14117 345 23 9 Telefonica del Sur S.A. 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 516 67 32 LINKdotNET AS number 20858 403 34 3 EgyNet 3741 265 855 223 The Internet Solution 2018 232 215 139 Tertiary Education Network 6713 143 135 11 Itissalat Al-MAGHRIB 33783 137 10 13 EEPAD TISP TELECOM & INTERNET 5536 120 8 17 Internet Egypt Network 5713 118 555 68 Telkom SA Ltd 33776 115 6 3 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 4292 3416 339 bellsouth.net, inc. 209 2927 4001 618 Qwest 6298 1980 316 736 Cox Communicatons 8151 1739 2877 226 UniNet S.A. de C.V. 4755 1721 538 181 Videsh Sanchar Nigam Ltd. Aut 20115 1689 1428 713 Charter Communications 1785 1656 710 156 AppliedTheory Corporation 2386 1550 691 892 AT&T Data Communications Serv 4323 1516 1065 368 Time Warner Telecom 7018 1402 5802 973 AT&T WorldNet Services Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2927 2309 Qwest 4755 1721 1540 Videsh Sanchar Nigam Ltd. Aut 8151 1739 1513 UniNet S.A. de C.V. 1785 1656 1500 AppliedTheory Corporation 17488 1384 1283 Hathway IP Over Cable Interne 6298 1980 1244 Cox Communicatons 11492 1217 1206 Cable One 4323 1516 1148 Time Warner Telecom 18566 1049 1039 Covad Communications 6478 1169 984 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 7018 AT&T WorldNet Servic 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 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.75.160.0/19 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 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio 63.143.71.0/24 701 UUNET Technologies, Inc. 63.143.115.0/24 701 UUNET Technologies, Inc. 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:17 /11:45 /12:147 /13:294 /14:529 /15:1072 /16:10090 /17:4390 /18:7733 /19:16281 /20:19082 /21:18612 /22:23366 /23:24446 /24:140670 /25:791 /26:968 /27:760 /28:89 /29:9 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2846 4292 bellsouth.net, inc. 6298 1955 1980 Cox Communicatons 209 1690 2927 Qwest 2386 1231 1550 AT&T Data Communications Serv 11492 1193 1217 Cable One 17488 1191 1384 Hathway IP Over Cable Interne 1785 1125 1656 AppliedTheory Corporation 6478 1062 1169 AT&T Worldnet Services 4755 1057 1721 Videsh Sanchar Nigam Ltd. Aut 18566 1030 1049 Covad Communications Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:8 8:139 12:2145 13:2 15:20 16:3 17:5 18:13 20:35 24:1087 32:59 38:494 40:91 41:723 43:1 44:2 47:12 52:3 55:3 56:3 57:26 58:527 59:520 60:451 61:950 62:1224 63:2033 64:3215 65:2381 66:3478 67:1243 68:780 69:2308 70:848 71:171 72:2026 73:7 74:1183 75:166 76:265 77:780 78:831 79:256 80:948 81:852 82:584 83:372 84:577 85:1018 86:399 87:713 88:336 89:1354 90:21 91:1497 92:264 93:836 94:147 96:65 97:80 98:321 99:8 114:105 115:47 116:987 117:365 118:229 119:500 120:86 121:593 122:853 123:443 124:857 125:1194 128:357 129:201 130:134 131:411 132:70 133:9 134:178 135:32 136:223 137:96 138:142 139:92 140:503 141:102 142:408 143:300 144:325 145:51 146:370 147:156 148:516 149:209 150:128 151:181 152:147 153:136 154:10 155:281 156:175 157:299 158:170 159:300 160:275 161:137 162:255 163:150 164:515 165:499 166:367 167:331 168:631 169:143 170:444 171:33 172:10 173:33 186:1 187:10 188:1 189:608 190:2262 192:5751 193:4144 194:3259 195:2579 196:996 198:3724 199:3297 200:5566 201:1505 202:7851 203:8093 204:3946 205:2136 206:2356 207:2731 208:3600 209:3411 210:2604 211:1088 212:1453 213:1622 214:178 215:50 216:4357 217:1213 218:345 219:437 220:1064 221:415 222:314 End of report -- This is the SANOG (http://www.sanog.org/) mailing list. From seph at directionless.org Fri Sep 19 19:53:01 2008 From: seph at directionless.org (seph) Date: Fri, 19 Sep 2008 20:53:01 -0400 Subject: LoA (Letter of Authorization) for Prefix Filter Modification? In-Reply-To: <48D28997.4000109@sprunk.org> (Stephen Sprunk's message of "Thu, 18 Sep 2008 12:02:15 -0500") References: <48D0BEA1.2040603@ipax.at> <200809171622.m8HGMKTI064265@aurora.sol.net> <2E2FECEBAE57CC4BAACDE67638305F1048120B7DF2@ROCH-EXCH1.corp.pvt> <48D28997.4000109@sprunk.org> Message-ID: Stephen Sprunk writes: > Azinger, Marla wrote: >> I use RWHOIS for proof of who we assign and allocate address space to. >> > > How is _you_ showing information in an RWHOIS server that _you_ > control in any way proving that the holder of a address block is > authorizing _you_ to advertise it on their behalf? At least in my case, it's not *my* rwhois server. My first ISP lists me as the owner/user/whatever in *their* rwhois server, and my second ISP considers that authoritative. seph From mksmith at adhost.com Sat Sep 20 18:56:57 2008 From: mksmith at adhost.com (Michael K. Smith) Date: Sat, 20 Sep 2008 16:56:57 -0700 Subject: LoA (Letter of Authorization) for Prefix Filter Modification? In-Reply-To: Message-ID: On 9/19/08 5:53 PM, "seph" wrote: > Stephen Sprunk writes: > >> Azinger, Marla wrote: >>> I use RWHOIS for proof of who we assign and allocate address space to. >>> >> >> How is _you_ showing information in an RWHOIS server that _you_ >> control in any way proving that the holder of a address block is >> authorizing _you_ to advertise it on their behalf? > > At least in my case, it's not *my* rwhois server. My first ISP lists me > as the owner/user/whatever in *their* rwhois server, and my second ISP > considers that authoritative. > Wouldn't it be interesting if every service provider would query the RIR's to find out who owns the block and then do some due diligence to make sure the block is being advertised by the right person. Mike From jthomas at crucialservers.net Sun Sep 21 13:06:20 2008 From: jthomas at crucialservers.net (James Thomas) Date: Sun, 21 Sep 2008 14:06:20 -0400 Subject: Atrivo/Intercage: NO Upstream depeered at 2:25am est In-Reply-To: <2B6AA123-9315-4EC6-9AB1-70C1E4E5311C@nosignal.org> Message-ID: <20080921180928.69CA761C20@crucialservers.net> Hmmm Seems Pacific bit the bullett around 2:25 est all annoucements were dropped. http://cidr-report.org/cgi-bin/as-report?as=AS27595&v=4&view=2.0 I would ask for comment by Intercage staff but they don't have email. Emil is unresponsive via phone, James From fergdawg at netzero.net Sun Sep 21 13:15:38 2008 From: fergdawg at netzero.net (Paul Ferguson) Date: Sun, 21 Sep 2008 18:15:38 GMT Subject: Atrivo/Intercage: NO Upstream depeered at 2:25am est Message-ID: <20080921.111538.10732.0@webmail09.vgs.untd.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- "James Thomas" wrote: >Hmmm Seems Pacific bit the bullett around 2:25 est all annoucements were >dropped. > >http://cidr-report.org/cgi-bin/as-report?as=AS27595&v=4&view=2.0 > While this is 'good' news, don't be foooled -- many of these prefixes have been migrated elsewhere, much the same way criminal activity was shifted to other hosting providers after the 'disappearance' of AS40989 last year). For example, see: http://www.cidr-report.org/cgi-bin/as-report?as=as36445&view=2.0 Tiscali in the only upstream for Cernel... - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI1o8/q1pz9mNUZTMRAveCAJ9CdMk5m35zwUAtkPrIGfHgPHFwsACbBRdd zhlVMo9Jrfwzyn0YsjSR1nI= =CIeo -----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 emilkacp at yahoo.com Sun Sep 21 14:20:20 2008 From: emilkacp at yahoo.com (Emil Kacperski) Date: Sun, 21 Sep 2008 12:20:20 -0700 (PDT) Subject: Atrivo/Intercage: NO Upstream depeer Message-ID: <514811.97087.qm@web38906.mail.mud.yahoo.com> Hello, It's true that David from PIE disconnected our link approx 9pm or so yesterday.? Things were going perfect, no complaints for a few weeks now.? The only thing I believe is that NTT gave lots of pressure to PIE.? For some unknown reason when I tried to reach out to the security guy at NTT he basically said our contract is with PIE. So in a time like this you really get to know who your friends are and who should be avoided. Onward and upward!? What doesn't kill you only makes you stronger ;-).? Just feel bad for the customers for which I am truly sorry for right now ;-(. Thanks! Contact: Emil Kacperski Company: Intercage Inc. - Atrivo Dedicated Servers San Francisco Datacenter E-Mail: emil at intercage.com Phone: 925-550-3947 ICQ: 23531098 From jthomas at crucialservers.net Sun Sep 21 14:28:26 2008 From: jthomas at crucialservers.net (James Thomas) Date: Sun, 21 Sep 2008 15:28:26 -0400 Subject: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <514811.97087.qm@web38906.mail.mud.yahoo.com> Message-ID: <20080921193135.3939E61C20@crucialservers.net> Emil, You have a lot of loyal legit customers. What's your plans? Seems like your taking action against the bad clients which is great. Where does this leave Intercage? You seeking alternative routes currently? Offering refunds to those loyal clients? James -----Original Message----- From: Emil Kacperski [mailto:emilkacp at yahoo.com] Sent: Sunday, September 21, 2008 3:20 PM To: nanog at nanog.org Subject: Re: Atrivo/Intercage: NO Upstream depeer Hello, It's true that David from PIE disconnected our link approx 9pm or so yesterday.? Things were going perfect, no complaints for a few weeks now.? The only thing I believe is that NTT gave lots of pressure to PIE.? For some unknown reason when I tried to reach out to the security guy at NTT he basically said our contract is with PIE. So in a time like this you really get to know who your friends are and who should be avoided. Onward and upward!? What doesn't kill you only makes you stronger ;-).? Just feel bad for the customers for which I am truly sorry for right now ;-(. Thanks! Contact: Emil Kacperski Company: Intercage Inc. - Atrivo Dedicated Servers San Francisco Datacenter E-Mail: emil at intercage.com Phone: 925-550-3947 ICQ: 23531098 From LarrySheldon at cox.net Sun Sep 21 14:29:45 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Sun, 21 Sep 2008 14:29:45 -0500 Subject: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <514811.97087.qm@web38906.mail.mud.yahoo.com> References: <514811.97087.qm@web38906.mail.mud.yahoo.com> Message-ID: <48D6A0A9.1090105@cox.net> Emil Kacperski wrote: > It's true that David from PIE disconnected our link approx 9pm or so > yesterday. Things were going perfect, no complaints for a few weeks > now. The only thing I believe is that NTT gave lots of pressure to > PIE. For some unknown reason when I tried to reach out to the > security guy at NTT he basically said our contract is with PIE. Some days the dragon wins, some days the knight does. From emilkacp at yahoo.com Sun Sep 21 14:46:54 2008 From: emilkacp at yahoo.com (Emil Kacperski) Date: Sun, 21 Sep 2008 12:46:54 -0700 (PDT) Subject: Atrivo/Intercage: NO Upstream depeer Message-ID: <492179.75767.qm@web38907.mail.mud.yahoo.com> Hey James, That's the worst part in all this, so many been with me for years!? I just put my fate into companies I shouldn't have.? NLayer was bought and Liteup held control of the SF pop, who is fully at the mercy of NLayer / ServerCentral.? WVFiber was bought by Host.NET and Randy simply made a choice.? And David from PIE I knew who he was from others but hey he has been at the datacenter with me for a number of years, so I gave him the benefit of the doubt. Spamhaus a few days ago added his IP's as a /22.? And surprise surprise now it's a /32! http://www.spamhaus.org/sbl/sbl.lasso?query=SBL67906 David didn't even have the balls to contact me and let me know what happened.? Has ignored any phone calls, etc.? Just told him router admin not to do anything without his approval.? In fact his technician acted at first as he didn't know what happened. Just need to put all this behind me.? Thanks! Contact: Emil Kacperski Company: Intercage Inc. - Atrivo Dedicated Servers San Francisco Datacenter E-Mail: emil at intercage.com Phone: 925-550-3947 ICQ: 23531098 From jonkman at jonkmans.com Sun Sep 21 15:08:33 2008 From: jonkman at jonkmans.com (Matt Jonkman) Date: Sun, 21 Sep 2008 16:08:33 -0400 Subject: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <492179.75767.qm@web38907.mail.mud.yahoo.com> References: <492179.75767.qm@web38907.mail.mud.yahoo.com> Message-ID: <48D6A9C1.20606@jonkmans.com> Had you responded to the hundreds of abuse complaints over the years this would not have happened. Sorry, no sympathy for you or the customers not smart enough to move over the last few years of very overt negative news about you. Matt Emil Kacperski wrote: > Hey James, > > That's the worst part in all this, so many been with me for years! I just put my fate into companies I shouldn't have. NLayer was bought and Liteup held control of the SF pop, who is fully at the mercy of NLayer / ServerCentral. WVFiber was bought by Host.NET and Randy simply made a choice. And David from PIE I knew who he was from others but hey he has been at the datacenter with me for a number of years, so I gave him the benefit of the doubt. > > Spamhaus a few days ago added his IP's as a /22. And surprise surprise now it's a /32! > > http://www.spamhaus.org/sbl/sbl.lasso?query=SBL67906 > > David didn't even have the balls to contact me and let me know what happened. Has ignored any phone calls, etc. Just told him router admin not to do anything without his approval. In fact his technician acted at first as he didn't know what happened. > > Just need to put all this behind me. > > Thanks! > > Contact: Emil Kacperski > > Company: Intercage Inc. - Atrivo > > Dedicated Servers > > San Francisco Datacenter > > E-Mail: emil at intercage.com > > Phone: 925-550-3947 > > ICQ: 23531098 > > > -- -------------------------------------------- Matthew Jonkman Emerging Threats Phone 765-429-0398 Fax 312-264-0205 http://www.emergingthreats.net -------------------------------------------- PGP: http://www.jonkmans.com/mattjonkman.asc From emilkacp at yahoo.com Sun Sep 21 15:21:20 2008 From: emilkacp at yahoo.com (Emil Kacperski) Date: Sun, 21 Sep 2008 13:21:20 -0700 (PDT) Subject: Atrivo/Intercage: NO Upstream depeer Message-ID: <784947.74534.qm@web38901.mail.mud.yahoo.com> Matt, Don't believe everything you read.? I have unfortunately been a target over the years because I rented machines to Esthost.? But the stories made up are way out there. It's all very easy a dedicated server / customer relationship - nothing more. Never did I ignore anymore from the abuse community.? Go ahead and find me a IP address that did any spam or anything.? You won't find it, I can't remember the last time I got any Spamcop complaints.? Not even going to mention Spamhaus because we all know there abuse. "We asked a handful of Intercage's most vocal critics if they sent take down requests to Kacperski. None said yes. "In his defense, what may have finally happened is that malware researchers stopped bothering to report" abusive sites," Eckelberry says." None said YES!? That pretty much sums it all up.? Maybe I could of reached out more, I guess that was my mistake.? But it surely is impossible to deal with if you have to deal with people like John Reid. Thanks!? Contact: Emil Kacperski Company: Intercage Inc. - Atrivo Dedicated Servers San Francisco Datacenter E-Mail: emil at intercage.com Phone: 925-550-3947 ICQ: 23531098 From patrick at ianai.net Sun Sep 21 15:29:05 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 21 Sep 2008 16:29:05 -0400 Subject: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <784947.74534.qm@web38901.mail.mud.yahoo.com> References: <784947.74534.qm@web38901.mail.mud.yahoo.com> Message-ID: <255D0D71-7C57-4A7E-8A5E-00962A17A89F@ianai.net> On Sep 21, 2008, at 4:21 PM, Emil Kacperski wrote: > Don't believe everything you read. Most excellent advice. [SNIP] -- TTFN, patrick From trelane at trelane.net Sun Sep 21 15:49:31 2008 From: trelane at trelane.net (Andrew D Kirch) Date: Sun, 21 Sep 2008 16:49:31 -0400 Subject: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <784947.74534.qm@web38901.mail.mud.yahoo.com> References: <784947.74534.qm@web38901.mail.mud.yahoo.com> Message-ID: <48D6B35B.1060605@trelane.net> Considering the years of abuse, DNSBL listings, ROKSO listings, further abuse, and silence at the abuse switch, I _CERTAINLY_ would not send Atrivo abuse reports, I would send them to the upstreams instead. Considering the almost 40 page white paper produced last month on the abuse from Atrivo, for me to change this practice, I would require: * a rapid, and verifiable response from Atrivo here over some period of time exceeding several months, and continuing thereafter, * the clearing of SBL/ROKSO records, and * a general reduction of abuse eminating from Atrivo. Andrew Emil Kacperski wrote: > Matt, > > Don't believe everything you read. I have unfortunately been a target over the years > because I rented machines to Esthost. But the stories made up are way out there. > It's all very easy a dedicated server / customer relationship - nothing more. > > Never did I ignore anymore from the abuse community. Go ahead and find me > a IP address that did any spam or anything. You won't find it, I can't remember > the last time I got any Spamcop complaints. Not even going to mention Spamhaus > because we all know there abuse. > > "We asked a handful of Intercage's most vocal critics if they sent take > down requests to Kacperski. None said yes. "In his defense, what may > have finally happened is that malware researchers stopped bothering to > report" abusive sites," Eckelberry says." > > None said YES! That pretty much sums it all up. Maybe I could of reached out > more, I guess that was my mistake. But it surely is impossible to deal with if > you have to deal with people like John Reid. > > Thanks! > > Contact: Emil Kacperski > > Company: Intercage Inc. - Atrivo > > Dedicated Servers > > San Francisco Datacenter > > E-Mail: emil at intercage.com > > Phone: 925-550-3947 > > ICQ: 23531098 > > > > From nenolod at systeminplace.net Sun Sep 21 16:03:20 2008 From: nenolod at systeminplace.net (William Pitcock) Date: Sun, 21 Sep 2008 16:03:20 -0500 Subject: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <48D6B35B.1060605@trelane.net> References: <784947.74534.qm@web38901.mail.mud.yahoo.com> <48D6B35B.1060605@trelane.net> Message-ID: <1222031000.20200.1201.camel@petrie.sacredspiral.co.uk> Greetings, I can further vouch for this... an unusually large amount of botnets reported to DroneBL have command and control servers on Atrivo's network. With the amount of listings and reports I get, it is obvious that Atrivo does not care about the abuse@ inbox... which is unfortunate. William On Sun, 2008-09-21 at 16:49 -0400, Andrew D Kirch wrote: > Considering the years of abuse, DNSBL listings, ROKSO listings, further > abuse, and silence at the abuse switch, I _CERTAINLY_ would not send > Atrivo abuse reports, I would send them to the upstreams instead. > Considering the almost 40 page white paper produced last month on the > abuse from Atrivo, for me to change this practice, I would require: > * a rapid, and verifiable response from Atrivo here over some > period of time exceeding several months, and continuing thereafter, > * the clearing of SBL/ROKSO records, and > * a general reduction of abuse eminating from Atrivo. > > Andrew > > > Emil Kacperski wrote: > > Matt, > > > > Don't believe everything you read. I have unfortunately been a target over the years > > because I rented machines to Esthost. But the stories made up are way out there. > > It's all very easy a dedicated server / customer relationship - nothing more. > > > > Never did I ignore anymore from the abuse community. Go ahead and find me > > a IP address that did any spam or anything. You won't find it, I can't remember > > the last time I got any Spamcop complaints. Not even going to mention Spamhaus > > because we all know there abuse. > > > > "We asked a handful of Intercage's most vocal critics if they sent take > > down requests to Kacperski. None said yes. "In his defense, what may > > have finally happened is that malware researchers stopped bothering to > > report" abusive sites," Eckelberry says." > > > > None said YES! That pretty much sums it all up. Maybe I could of reached out > > more, I guess that was my mistake. But it surely is impossible to deal with if > > you have to deal with people like John Reid. > > > > Thanks! > > > > Contact: Emil Kacperski > > > > Company: Intercage Inc. - Atrivo > > > > Dedicated Servers > > > > San Francisco Datacenter > > > > E-Mail: emil at intercage.com > > > > Phone: 925-550-3947 > > > > ICQ: 23531098 > > > > > > > > > > From jonkman at jonkmans.com Sun Sep 21 16:32:26 2008 From: jonkman at jonkmans.com (Matt Jonkman) Date: Sun, 21 Sep 2008 17:32:26 -0400 Subject: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <784947.74534.qm@web38901.mail.mud.yahoo.com> References: <784947.74534.qm@web38901.mail.mud.yahoo.com> Message-ID: <48D6BD6A.5000103@jonkmans.com> Emil Kacperski wrote: > Don't believe everything you read. I have unfortunately been a target over the years > because I rented machines to Esthost. But the stories made up are way out there. > It's all very easy a dedicated server / customer relationship - nothing more. I don't have to believe what I read. I did the research, and I helped write the reports. Have to say I'm VERY proud of contributing to getting you offline. It's not just estdomains. In fact very little of them is related to you. It's the botnet controllers, spam, phishing sites, etc. If you think those things trivial then you need to remain offline. > > Never did I ignore anymore from the abuse community. Go ahead and find me > a IP address that did any spam or anything. You won't find it, I can't remember > the last time I got any Spamcop complaints. Not even going to mention Spamhaus > because we all know there abuse. > You ignored MY abuse complaints. You ignored MY emails to cooperate in getting your net cleaned up. I have HUNDREDS of malware samples using your nets as CnC just in the last few months! So rather than wasting my time emailing your abuse blackhole I helped write a report about you. Time well spent I think. > "We asked a handful of Intercage's most vocal critics if they sent take > down requests to Kacperski. None said yes. "In his defense, what may > have finally happened is that malware researchers stopped bothering to > report" abusive sites," Eckelberry says." They didn't ask me. I sent plenty. And if you read his full comments I'm sure he goes on to say "because they were tired of having their time wasted by you ignoring them for YEARS!" But this thread isn't what nanog is for. We should end this here, until Emil finds someone else willing to peer his crap. Then we can decide how to get that handled. Matt > > None said YES! That pretty much sums it all up. Maybe I could of reached out > more, I guess that was my mistake. But it surely is impossible to deal with if > you have to deal with people like John Reid. > > Thanks! > > Contact: Emil Kacperski > > Company: Intercage Inc. - Atrivo > > Dedicated Servers > > San Francisco Datacenter > > E-Mail: emil at intercage.com > > Phone: 925-550-3947 > > ICQ: 23531098 > > > -- -------------------------------------------- Matthew Jonkman Emerging Threats Phone 765-429-0398 Fax 312-264-0205 http://www.emergingthreats.net -------------------------------------------- PGP: http://www.jonkmans.com/mattjonkman.asc From russm2k8 at yahoo.com Sun Sep 21 16:54:04 2008 From: russm2k8 at yahoo.com (Russell Mitchell) Date: Sun, 21 Sep 2008 14:54:04 -0700 (PDT) Subject: Atrivo/Intercage: NO Upstream depeer Message-ID: <731944.9379.qm@web45014.mail.sp1.yahoo.com> Hello all, Andrew: It is truly enlightening, to say the least,?that you want to talk about all of the SBL Listings, all of the DNSBL Listings, and all of the abuse on our network?has never had action taken. ----- In Spamhaus' article, they did a history of more then ?350? SBL Listings for our company. Today, we have 6 ACTIVE Listings in the SBL. If we haven't acted on abuse claims, why do those numbers not match up? So, sometime over the weekend, Spamhaus listed our ONLY Upstream's /22 IP Block.. There's NO Evidence of any abuse from PIE for the listing.?How can they be labeled as a SPAM or Abuse Supporter after?routing us for such a short time??That's ethical, legitimate, and reasonable to you? We have ALL of our IP Space listed with Spamhaus because we have a Reseller named Esthost. While their customer track record may not be a straight arrow, they've ALWAYS taken action on abuse we've received for machines leased to them (Just like every other customer we have!). We enacted a zero tolerance policy in light of the community delivering false information and giving false reports to news media. What did that do? It gave us the opportunity to cancel service on EVERY Machine that an abuse was reported on. What happened shortly after? No more reports, no more abuse. Esthost's Registrar entity, EstDomains launched a great campaign to work with the public and take in reports against Malware Customers, as that is what the news media was reporting was the issue. Over 20,000 Domains get suspended by EstDomains in a period of about a week. Your going to come back and say, "Well Directi did it in about 2 days!". Yeah? Directi had it placed right on their desk! They didn't have to launch any campaign or go out and ask the COMMUNITY for it. The people behind those false reports on our company gave them a set of Data to allow them to act that fast. So, we see Esthost turning a corner and going out to the community with an outreach program. Community is giving support for it. We enact a zero tolerance policy for our entire network, this isn't made public aside to a GOOD and TRUTHFUL Editor from TheRegister, Dan Goodin. We gave ourselves 1 month to see what is going to happen between the community, and Esthost. In the final stretch of that 1 month, we get blind-sided by Spamhaus. So now, an apparently level-headed James Thomas brings the happenings from last night into the light, and here we are. All of the claims about us being the RBN, Emil being some Russian named "Igor", and "Atrivo" being the epicenter with such partners like InterCage. Did you forget? Emil has a split-personality, that's how they got their claim of InterCage being partnered with Atrivo. As though they're 2 seperate entities! Good Research Matt, Jart, Garth, and all the others who've written about us recently! Thank you all for your time and responses. Good or bad, we're reading them. Have a great day. --- Russell Mitchell InterCage, Inc. - An un-orgranized eCrime ring based out of San Francisco, CA.?We would only be so lucky! From ge at linuxbox.org Sun Sep 21 17:13:45 2008 From: ge at linuxbox.org (Gadi Evron) Date: Sun, 21 Sep 2008 17:13:45 -0500 (CDT) Subject: Atrivo/Intercage: NO Upstream depeered at 2:25am est In-Reply-To: <20080921.111538.10732.0@webmail09.vgs.untd.com> References: <20080921.111538.10732.0@webmail09.vgs.untd.com> Message-ID: On Sun, 21 Sep 2008, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > - -- "James Thomas" wrote: > >> Hmmm Seems Pacific bit the bullett around 2:25 est all annoucements were >> dropped. >> >> http://cidr-report.org/cgi-bin/as-report?as=AS27595&v=4&view=2.0 >> > > While this is 'good' news, don't be foooled -- many of these prefixes > have been migrated elsewhere, much the same way criminal activity > was shifted to other hosting providers after the 'disappearance' > of AS40989 last year). > > For example, see: > > http://www.cidr-report.org/cgi-bin/as-report?as=as36445&view=2.0 > > Tiscali in the only upstream for Cernel... Are they all moving to Cernel as predicted, or are some of the prefixes coming from elsewhere? > - - ferg > > -----BEGIN PGP SIGNATURE----- > Version: PGP Desktop 9.6.3 (Build 3017) > > wj8DBQFI1o8/q1pz9mNUZTMRAveCAJ9CdMk5m35zwUAtkPrIGfHgPHFwsACbBRdd > zhlVMo9Jrfwzyn0YsjSR1nI= > =CIeo > -----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 russm2k8 at yahoo.com Sun Sep 21 17:17:02 2008 From: russm2k8 at yahoo.com (Russell Mitchell) Date: Sun, 21 Sep 2008 15:17:02 -0700 (PDT) Subject: Atrivo/Intercage: NO Upstream depeer Message-ID: <580028.25535.qm@web45001.mail.sp1.yahoo.com> William: To date, I have never heard of the "DroneBL". I have NEVER received any report from any entity?referring to that.?The last report for a bot on our network was an EggDrop bot a week or so ago. The report?was from the IRC Network Operator, and asked to have it?removed from his network because it seemed?to be?'forgotten'. It was sitting in a dead channel?that hasn't had any activity for months. He did NOT claim any abuse. I'll be?more then happy to monitor DroneBL, or have digests or reports from them in regards to our network. ----- Matt: It's very sad that your?PROUD of?you contribution?to the?supposed "white paper" on our company.?I'd like to know, was any of your "contribution" to the report altered, or mis-represented, or are you?truly unaware of how false the information you provided was? Care to have verified it? or are you a Spamhaus admin like John Reid who has that magic stick to make a claim and attack anyone who objects to it with the truth? If you want to see REAL Cyber Crime, take a look at what you caused Matt. Take a good look at Spamhaus, and tell me that they're entirely legitimate with their business. Oh, I forgot, they're a "Not-for-profit organization" that DOESN'T do business in the USA, nor has any clientel in the USA. ----- There is absolutely no sense in arguing and biquering over all this crap that you guys have caused with your misinformation and false claims. I don't know how to make this any simpler:?If you see abuse from our network, report it to US. If you report it to an upstream, they'll just drop it back down to us. Obviously, we can't do anything right now with our network being OFFLINE.. But I'm dying to see who comes up with some abuse that originated from our network in this downtime! Who will be first!? Spamhaus? Thanks again for all your time and comments. Hopefully,?you all will straighten up your act, cause clearly and truthfully, we've been straight the entire time. ?--- Russell Mitchell InterCage, Inc. From jthomas at crucialservers.net Sun Sep 21 17:18:31 2008 From: jthomas at crucialservers.net (James Thomas) Date: Sun, 21 Sep 2008 18:18:31 -0400 Subject: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <731944.9379.qm@web45014.mail.sp1.yahoo.com> Message-ID: <20080921222141.97A0261C2B@crucialservers.net> Russell, I really think Atrivo/Intercage has been doing great after reports and community public action. I'm still puzzled as to the why they are still targetting you? I have a few friends who have machines with you so and they run legitimate companies with over 4 machines. Emil has done everything in his power to bring his network back to normal operations. Looks great the past 2 weeks, I wish both of you the best of luck its hard to determine who is a solid friend and who is not. Like emil said... It only will make you stronger. James -----Original Message----- From: Russell Mitchell [mailto:russm2k8 at yahoo.com] Sent: Sunday, September 21, 2008 5:54 PM To: nanog at nanog.org Subject: Re: Atrivo/Intercage: NO Upstream depeer Hello all, Andrew: It is truly enlightening, to say the least,?that you want to talk about all of the SBL Listings, all of the DNSBL Listings, and all of the abuse on our network?has never had action taken. ----- In Spamhaus' article, they did a history of more then ?350? SBL Listings for our company. Today, we have 6 ACTIVE Listings in the SBL. If we haven't acted on abuse claims, why do those numbers not match up? So, sometime over the weekend, Spamhaus listed our ONLY Upstream's /22 IP Block.. There's NO Evidence of any abuse from PIE for the listing.?How can they be labeled as a SPAM or Abuse Supporter after?routing us for such a short time??That's ethical, legitimate, and reasonable to you? We have ALL of our IP Space listed with Spamhaus because we have a Reseller named Esthost. While their customer track record may not be a straight arrow, they've ALWAYS taken action on abuse we've received for machines leased to them (Just like every other customer we have!). We enacted a zero tolerance policy in light of the community delivering false information and giving false reports to news media. What did that do? It gave us the opportunity to cancel service on EVERY Machine that an abuse was reported on. What happened shortly after? No more reports, no more abuse. Esthost's Registrar entity, EstDomains launched a great campaign to work with the public and take in reports against Malware Customers, as that is what the news media was reporting was the issue. Over 20,000 Domains get suspended by EstDomains in a period of about a week. Your going to come back and say, "Well Directi did it in about 2 days!". Yeah? Directi had it placed right on their desk! They didn't have to launch any campaign or go out and ask the COMMUNITY for it. The people behind those false reports on our company gave them a set of Data to allow them to act that fast. So, we see Esthost turning a corner and going out to the community with an outreach program. Community is giving support for it. We enact a zero tolerance policy for our entire network, this isn't made public aside to a GOOD and TRUTHFUL Editor from TheRegister, Dan Goodin. We gave ourselves 1 month to see what is going to happen between the community, and Esthost. In the final stretch of that 1 month, we get blind-sided by Spamhaus. So now, an apparently level-headed James Thomas brings the happenings from last night into the light, and here we are. All of the claims about us being the RBN, Emil being some Russian named "Igor", and "Atrivo" being the epicenter with such partners like InterCage. Did you forget? Emil has a split-personality, that's how they got their claim of InterCage being partnered with Atrivo. As though they're 2 seperate entities! Good Research Matt, Jart, Garth, and all the others who've written about us recently! Thank you all for your time and responses. Good or bad, we're reading them. Have a great day. --- Russell Mitchell InterCage, Inc. - An un-orgranized eCrime ring based out of San Francisco, CA.?We would only be so lucky! From ge at linuxbox.org Sun Sep 21 17:22:35 2008 From: ge at linuxbox.org (Gadi Evron) Date: Sun, 21 Sep 2008 17:22:35 -0500 (CDT) Subject: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <731944.9379.qm@web45014.mail.sp1.yahoo.com> References: <731944.9379.qm@web45014.mail.sp1.yahoo.com> Message-ID: On Sun, 21 Sep 2008, Russell Mitchell wrote: > Hello all, > > Andrew: > It is truly enlightening, to say the least,?that you want to talk about all of the SBL Listings, all of the DNSBL Listings, and all of the abuse on our network?has never had action taken. "Don't kick someone when they are down". Okay. I have but one question, why are you speaking to us all now, instead of last week or last month? Gadi. > ----- > > In Spamhaus' article, they did a history of more then ?350? SBL Listings for our company. Today, we have 6 ACTIVE Listings in the SBL. If we haven't acted on abuse claims, why do those numbers not match up? > > So, sometime over the weekend, Spamhaus listed our ONLY Upstream's /22 IP Block.. There's NO Evidence of any abuse from PIE for the listing.?How can they be labeled as a SPAM or Abuse Supporter after?routing us for such a short time??That's ethical, legitimate, and reasonable to you? > > We have ALL of our IP Space listed with Spamhaus because we have a Reseller named Esthost. While their customer track record may not be a straight arrow, they've ALWAYS taken action on abuse we've received for machines leased to them (Just like every other customer we have!). > > We enacted a zero tolerance policy in light of the community delivering false information and giving false reports to news media. What did that do? It gave us the opportunity to cancel service on EVERY Machine that an abuse was reported on. > What happened shortly after? No more reports, no more abuse. > > Esthost's Registrar entity, EstDomains launched a great campaign to work with the public and take in reports against Malware Customers, as that is what the news media was reporting was the issue. Over 20,000 Domains get suspended by EstDomains in a period of about a week. Your going to come back and say, "Well Directi did it in about 2 days!". Yeah? Directi had it placed right on their desk! They didn't have to launch any campaign or go out and ask the COMMUNITY for it. The people behind those false reports on our company gave them a set of Data to allow them to act that fast. > > So, we see Esthost turning a corner and going out to the community with an outreach program. Community is giving support for it. > We enact a zero tolerance policy for our entire network, this isn't made public aside to a GOOD and TRUTHFUL Editor from TheRegister, Dan Goodin. > We gave ourselves 1 month to see what is going to happen between the community, and Esthost. In the final stretch of that 1 month, we get blind-sided by Spamhaus. > > So now, an apparently level-headed James Thomas brings the happenings from last night into the light, and here we are. > All of the claims about us being the RBN, Emil being some Russian named "Igor", and "Atrivo" being the epicenter with such partners like InterCage. Did you forget? Emil has a split-personality, that's how they got their claim of InterCage being partnered with Atrivo. As though they're 2 seperate entities! Good Research Matt, Jart, Garth, and all the others who've written about us recently! > > Thank you all for your time and responses. Good or bad, we're reading them. Have a great day. > > --- > Russell Mitchell > InterCage, Inc. - An un-orgranized eCrime ring based out of San Francisco, CA.?We would only be so lucky! > > > > From fergdawg at netzero.net Sun Sep 21 17:33:31 2008 From: fergdawg at netzero.net (Paul Ferguson) Date: Sun, 21 Sep 2008 22:33:31 GMT Subject: Atrivo/Intercage: NO Upstream depeered at 2:25am est Message-ID: <20080921.153331.25045.0@webmail05.vgs.untd.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Gadi Evron wrote: >>> >>> http://cidr-report.org/cgi-bin/as-report?as=AS27595&v=4&view=2.0 >>> >> >> While this is 'good' news, don't be foooled -- many of these prefixes >> have been migrated elsewhere, much the same way criminal activity >> was shifted to other hosting providers after the 'disappearance' >> of AS40989 last year). >> >> For example, see: >> >> http://www.cidr-report.org/cgi-bin/as-report?as=as36445&view=2.0 >> > Tiscali in the only upstream for Cernel... > >Are they all moving to Cernel as predicted, or are some of the prefixes >coming from elsewhere? The only prefixes that were being originated by AS27595 which are now being originated elsewhere (at least that I've seen) are: AS27595: - 85.255.113.0/24 Withdrawn - 85.255.114.0/23 Withdrawn - 85.255.116.0/22 Withdrawn - 85.255.120.0/23 Withdrawn - 85.255.122.0/24 Withdrawn AS36445: Prefix AS Path 85.255.112.0/20 12654 3257 36445 - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI1suyq1pz9mNUZTMRAhvOAJ9VKLoPtrQ8QYJTJlAspxoiKgooeACgtdGT AuaBR6QAkHlvrplNjEppamc= =wYt3 -----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 trelane at trelane.net Sun Sep 21 17:48:35 2008 From: trelane at trelane.net (Andrew D Kirch) Date: Sun, 21 Sep 2008 18:48:35 -0400 Subject: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <731944.9379.qm@web45014.mail.sp1.yahoo.com> References: <731944.9379.qm@web45014.mail.sp1.yahoo.com> Message-ID: <48D6CF43.2080406@trelane.net> Russell Mitchell wrote: > Hello all, > > Andrew: > It is truly enlightening, to say the least, that you want to talk about all of the SBL Listings, all of the DNSBL Listings, and all of the abuse on our network has never had action taken. > > ----- > > In Spamhaus' article, they did a history of more then ?350? SBL Listings for our company. Today, we have 6 ACTIVE Listings in the SBL. If we haven't acted on abuse claims, why do those numbers not match up? > I didn't say deal with some of them, I said deal with _ALL_ of them. I have 0 SBL Listings, 0 ROKSO listings. There's not an acceptable minimum. Don't host abusers, period. No points are given for half effort. > So, sometime over the weekend, Spamhaus listed our ONLY Upstream's /22 IP Block.. There's NO Evidence of any abuse from PIE for the listing. How can they be labeled as a SPAM or Abuse Supporter after routing us for such a short time? That's ethical, legitimate, and reasonable to you? > There were listings of PIE earlier this week as well. I am not with Spamhaus and I don't speak for them, but I think that the legitimacy threshold is met by being consistent with their own listing criteria. As you have nothing other than a vague insinuation otherwise, your claim here fails. > We have ALL of our IP Space listed with Spamhaus because we have a Reseller named Esthost. While their customer track record may not be a straight arrow, they've ALWAYS taken action on abuse we've received for machines leased to them (Just like every other customer we have!). > Damn, did you forgot the botnet C&C's? The Credit Card Fraud, the 40 page report documenting Atrivo's abuse of the Internet? > We enacted a zero tolerance policy in light of the community delivering false information and giving false reports to news media. What did that do? It gave us the opportunity to cancel service on EVERY Machine that an abuse was reported on. > What happened shortly after? No more reports, no more abuse. > 0 Tolerance = 6 SBL listings? 0 != 6 > Esthost's Registrar entity, EstDomains launched a great campaign to work with the public and take in reports against Malware Customers, as that is what the news media was reporting was the issue. Over 20,000 Domains get suspended by EstDomains in a period of about a week. Your going to come back and say, "Well Directi did it in about 2 days!". Yeah? Directi had it placed right on their desk! They didn't have to launch any campaign or go out and ask the COMMUNITY for it. The people behind those false reports on our company gave them a set of Data to allow them to act that fast. > Directi was a slightly stagnate pond compared to the sewer which is Atrivo. > So, we see Esthost turning a corner and going out to the community with an outreach program. Community is giving support for it. > We enact a zero tolerance policy for our entire network, this isn't made public aside to a GOOD and TRUTHFUL Editor from TheRegister, Dan Goodin. > We gave ourselves 1 month to see what is going to happen between the community, and Esthost. In the final stretch of that 1 month, we get blind-sided by Spamhaus. > Yep, the British Tabloids are always accurate. Dan's pretty new there, and they have better security writers. > So now, an apparently level-headed James Thomas brings the happenings from last night into the light, and here we are. > All of the claims about us being the RBN, Emil being some Russian named "Igor", and "Atrivo" being the epicenter with such partners like InterCage. Did you forget? Emil has a split-personality, that's how they got their claim of InterCage being partnered with Atrivo. As though they're 2 seperate entities! Good Research Matt, Jart, Garth, and all the others who've written about us recently! After the years of abuse it doesn't matter if there's a factual basis for where I send my e-mail reports (I think I've demonstrated that there still is), or merely a visceral dislike of the long-standing business practices at Atrivo (I think I've demonstrated that as well). Andrew From trelane at trelane.net Sun Sep 21 17:50:07 2008 From: trelane at trelane.net (Andrew D Kirch) Date: Sun, 21 Sep 2008 18:50:07 -0400 Subject: Atrivo/Intercage: NO Upstream depeer In-Reply-To: References: <731944.9379.qm@web45014.mail.sp1.yahoo.com> Message-ID: <48D6CF9F.6090804@trelane.net> Gadi Evron wrote: > On Sun, 21 Sep 2008, Russell Mitchell wrote: >> Hello all, >> >> Andrew: >> It is truly enlightening, to say the least, that you want to talk >> about all of the SBL Listings, all of the DNSBL Listings, and all of >> the abuse on our network has never had action taken. > > "Don't kick someone when they are down". Okay. > > I have but one question, why are you speaking to us all now, instead > of last week or last month? > > Gadi. I think he figured out that there's bite to go with the bark. Andrew From jonkman at jonkmans.com Sun Sep 21 18:02:15 2008 From: jonkman at jonkmans.com (Matt Jonkman) Date: Sun, 21 Sep 2008 19:02:15 -0400 Subject: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <580028.25535.qm@web45001.mail.sp1.yahoo.com> References: <580028.25535.qm@web45001.mail.sp1.yahoo.com> Message-ID: <48D6D277.9070807@jonkmans.com> Russell Mitchell wrote: > ----- > > Matt: > It's very sad that your PROUD of you contribution to the supposed "white paper" on our company. I'd like to know, was any of your "contribution" to the report altered, or mis-represented, or are you truly unaware of how false the information you provided was? > Care to have verified it? or are you a Spamhaus admin like John Reid who has that magic stick to make a claim and attack anyone who objects to it with the truth? I'd love to, but nanog isn't the place. I'll be in san fran in the near future. Lets sit down over a beer, I'll bring the research and you can look it over yourself. That would be far more productive than this. I think a few other folks would love to meet up with you as well. Maybe Emil can join us too? It's easy to insinuate from behind a keyboard. Lets get down to facts. But take this off nanog. This is NOT the place for it. Let me know when you'l be in town, I'll schedule my travel in that direction to meet up soon. Matt -- -------------------------------------------- Matthew Jonkman Emerging Threats Phone 765-429-0398 Fax 312-264-0205 http://www.emergingthreats.net -------------------------------------------- PGP: http://www.jonkmans.com/mattjonkman.asc From trelane at trelane.net Sun Sep 21 18:16:15 2008 From: trelane at trelane.net (Andrew D Kirch) Date: Sun, 21 Sep 2008 19:16:15 -0400 Subject: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <676622.49744.qm@web45010.mail.sp1.yahoo.com> References: <676622.49744.qm@web45010.mail.sp1.yahoo.com> Message-ID: <48D6D5BF.8010304@trelane.net> Russell Mitchell wrote: > Andrew: > If you have seen how Spamhaus handles our resolved SBL Listings, you > would know. > Those 6 listings have been resolved for a week now. John Reid and > his goons only provide swift LISTINGS, _NOT_ delistings. > Possibly why they're so widely used. > > In the past 12 months, I have received not 1 report of a botnet on our > network. Your e-mail is broken, or you're a liar, or both > Phishing pages are always nullrouted at the time of the report. The > "40 page report" you keep referring to is a complete farse. it's 'farce' but that couldn't matter less. > But, undoubtably, you truly believe that there is an "Atrivo" and > InterCage is a "partner in crime" to Atrivo huh? Results *1* - *10* of about *26,900* for atrivo. Results *1* - *10* of about *2,390* for *atrivo crime *. Results *1* - *10* of about *1,880* for *atrivo fraud *. Results *1* - *10* of about *1,100* for *atrivo phish*. It seems that at least 26,900 people join me in the first fantasy, and 6000 or so join me in the second. Cult meetings are on Thrusday, we'll sacrifice a spammer. > Anything else you'd like to throw at me here on NANOG? Sure, but I havn't figured out how to hit someone with a two-by-four over the Internet. > I truly feel that there are very FEW in the anti-abuse community > that smelling fresh air. If you knew where you head was, and where it > should be, maybe this conversation and the happenings in the recent > week would have actually gave benefit to the internet in whole. Atrivo/Intercage is off the Internet. That sounds like Mission Accomplished to me. I'm done now, there's clearly nothing I can do to impart a clue here. Andrew From russm2k8 at yahoo.com Sun Sep 21 18:21:47 2008 From: russm2k8 at yahoo.com (Russell Mitchell) Date: Sun, 21 Sep 2008 16:21:47 -0700 (PDT) Subject: Atrivo/Intercage: NO Upstream depeer Message-ID: <981607.33089.qm@web45016.mail.sp1.yahoo.com> Matt: I've already put this offer up. I'll be more then happy to meet up at our datacenter?and take you?through our space. What I find funny is, your the first one?whom participated in the recent reports to actually take up and respond to?us. I've emailed Garth and?Jart, and both of them refused to respond. I emailed both of them requesting the same information they gave to Directi. If they were able to provide Directi with a list of 20,000+ domains?from their control that were abusive, why can't they provide US directly with a single 1? Then, release a joint-statement talking about how the?companies need to come together to combat the abusive activities across the net,?yet when we?extend our hand and open up our network, we don't even get a response! Directi went from being a "partner in crime" with us to being a great anti-abuse supporting company.. How can YOU claim that WE don't do anything, if you won't report your findings in the first place? Got recent stuff? Why?are you willing to give it now that we're OFFLINE? What can we do about?it NOW at this very minute? You tell me when your going to be in San Francisco, and I'll make myself available. Thank you for your time. Have a great day. ?--- Russell Mitchell InterCage, Inc. P.S. I just realized all my responses to earlier people like Gadi and them were direct and not cc to NANOG. Will "Reply to all" now :) ----- Original Message ---- From: Matt Jonkman To: Russell Mitchell Cc: nanog at nanog.org Sent: Sunday, September 21, 2008 4:02:15 PM Subject: Re: Atrivo/Intercage: NO Upstream depeer Russell Mitchell wrote: > ----- > > Matt: > It's very sad that your PROUD of you contribution to the supposed "white paper" on our company. I'd like to know, was any of your "contribution" to the report altered, or mis-represented, or are you truly unaware of how false the information you provided was? > Care to have verified it? or are you a Spamhaus admin like John Reid who has that magic stick to make a claim and attack anyone who objects to it with the truth? I'd love to, but nanog isn't the place. I'll be in san fran in the near future. Lets sit down over a beer, I'll bring the research and you can look it over yourself. That would be far more productive than this. I think a few other folks would love to meet up with you as well. Maybe Emil can join us too? It's easy to insinuate from behind a keyboard. Lets get down to facts. But take this off nanog. This is NOT the place for it. Let me know when you'l be in town, I'll schedule my travel in that direction to meet up soon. Matt -- -------------------------------------------- Matthew Jonkman Emerging Threats Phone 765-429-0398 Fax 312-264-0205 http://www.emergingthreats.net -------------------------------------------- PGP: http://www.jonkmans.com/mattjonkman.asc From jonkman at jonkmans.com Sun Sep 21 18:58:21 2008 From: jonkman at jonkmans.com (Matt Jonkman) Date: Sun, 21 Sep 2008 19:58:21 -0400 Subject: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <981607.33089.qm@web45016.mail.sp1.yahoo.com> References: <981607.33089.qm@web45016.mail.sp1.yahoo.com> Message-ID: <48D6DF9D.8020504@jonkmans.com> I will do so. Look forward to the tour. Matt Russell Mitchell wrote: > Matt: > I've already put this offer up. I'll be more then happy to meet up at > our datacenter and take you through our space. > What I find funny is, your the first one whom participated in the recent > reports to actually take up and respond to us. > I've emailed Garth and Jart, and both of them refused to respond. > > I emailed both of them requesting the same information they gave to > Directi. If they were able to provide Directi with a list of 20,000+ > domains from their control that were abusive, why can't they provide US > directly with a single 1? > > Then, release a joint-statement talking about how the companies need to > come together to combat the abusive activities across the net, yet when > we extend our hand and open up our network, we don't even get a response! > > Directi went from being a "partner in crime" with us to being a great > anti-abuse supporting company. How can YOU claim that WE don't do > anything, if you won't report your findings in the first place? Got > recent stuff? Why are you willing to give it now that we're OFFLINE? > What can we do about it NOW at this very minute? > > You tell me when your going to be in San Francisco, and I'll make myself > available. > > Thank you for your time. Have a great day. > > --- > Russell Mitchell > InterCage, Inc. > > P.S. I just realized all my responses to earlier people like Gadi and > them were direct and not cc to NANOG. Will "Reply to all" now :) > > ----- Original Message ---- > From: Matt Jonkman > To: Russell Mitchell > Cc: nanog at nanog.org > Sent: Sunday, September 21, 2008 4:02:15 PM > Subject: Re: Atrivo/Intercage: NO Upstream depeer > > Russell Mitchell wrote: >> ----- >> >> Matt: >> It's very sad that your PROUD of you contribution to the supposed > "white paper" on our company. I'd like to know, was any of your > "contribution" to the report altered, or mis-represented, or are you > truly unaware of how false the information you provided was? >> Care to have verified it? or are you a Spamhaus admin like John Reid > who has that magic stick to make a claim and attack anyone who objects > to it with the truth? > > I'd love to, but nanog isn't the place. I'll be in san fran in the near > future. Lets sit down over a beer, I'll bring the research and you can > look it over yourself. That would be far more productive than this. I > think a few other folks would love to meet up with you as well. Maybe > Emil can join us too? > > It's easy to insinuate from behind a keyboard. Lets get down to facts. > > But take this off nanog. This is NOT the place for it. Let me know when > you'l be in town, I'll schedule my travel in that direction to meet up soon. > > Matt > > -- > -------------------------------------------- > Matthew Jonkman > Emerging Threats > Phone 765-429-0398 > Fax 312-264-0205 > http://www.emergingthreats.net > -------------------------------------------- > > PGP: http://www.jonkmans.com/mattjonkman.asc > > > -- -------------------------------------------- Matthew Jonkman Emerging Threats Phone 765-429-0398 Fax 312-264-0205 http://www.emergingthreats.net -------------------------------------------- PGP: http://www.jonkmans.com/mattjonkman.asc From darkuncle at gmail.com Mon Sep 22 09:34:52 2008 From: darkuncle at gmail.com (Scott Francis) Date: Mon, 22 Sep 2008 07:34:52 -0700 Subject: hat tip to .gov hostmasters Message-ID: <4EBDBF94-62BD-48E9-A262-A4E9E91249E4@gmail.com> http://it.slashdot.org/article.pl?sid=08/09/22/1253201&from=rss nice to see a wholesale DNSSEC rollout underway (I must confess to being a little surprised at the source, too!). Granted, it's a much more manageable problem set than, say, .com - but if one US-controlled TLD can do it, hope is buoyed for a .com rollout sooner rather than later (although probably not much sooner :)). /sf -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From xenophage0 at gmail.com Mon Sep 22 09:52:42 2008 From: xenophage0 at gmail.com (Jason Frisvold) Date: Mon, 22 Sep 2008 10:52:42 -0400 Subject: hat tip to .gov hostmasters In-Reply-To: <4EBDBF94-62BD-48E9-A262-A4E9E91249E4@gmail.com> References: <4EBDBF94-62BD-48E9-A262-A4E9E91249E4@gmail.com> Message-ID: <924f29280809220752i646b69e5u5455ac5426f0cc07@mail.gmail.com> On Mon, Sep 22, 2008 at 10:34 AM, Scott Francis wrote: > nice to see a wholesale DNSSEC rollout underway (I must confess to being a > little surprised at the source, too!). Granted, it's a much more manageable > problem set than, say, .com - but if one US-controlled TLD can do it, hope > is buoyed for a .com rollout sooner rather than later (although probably not > much sooner :)). I'm not much up on DNSSEC, but don't you need to be using a resolver that recognizes DNSSEC in order for this to be useful? > /sf -- Jason 'XenoPhage' Frisvold XenoPhage0 at gmail.com http://blog.godshell.com From fweimer at bfk.de Mon Sep 22 09:56:20 2008 From: fweimer at bfk.de (Florian Weimer) Date: Mon, 22 Sep 2008 16:56:20 +0200 Subject: hat tip to .gov hostmasters In-Reply-To: <924f29280809220752i646b69e5u5455ac5426f0cc07@mail.gmail.com> (Jason Frisvold's message of "Mon, 22 Sep 2008 10:52:42 -0400") References: <4EBDBF94-62BD-48E9-A262-A4E9E91249E4@gmail.com> <924f29280809220752i646b69e5u5455ac5426f0cc07@mail.gmail.com> Message-ID: <82ljxkkz57.fsf@mid.bfk.de> * Jason Frisvold: > On Mon, Sep 22, 2008 at 10:34 AM, Scott Francis wrote: >> nice to see a wholesale DNSSEC rollout underway (I must confess to being a >> little surprised at the source, too!). Granted, it's a much more manageable >> problem set than, say, .com - but if one US-controlled TLD can do it, hope >> is buoyed for a .com rollout sooner rather than later (although probably not >> much sooner :)). > > I'm not much up on DNSSEC, but don't you need to be using a resolver > that recognizes DNSSEC in order for this to be useful? Correct, you need a validating, security-aware stub resolver, or the ISP needs to validate the records for you. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From nanog at castalie.org Mon Sep 22 09:59:37 2008 From: nanog at castalie.org (Simon Vallet) Date: Mon, 22 Sep 2008 16:59:37 +0200 Subject: hat tip to .gov hostmasters In-Reply-To: <924f29280809220752i646b69e5u5455ac5426f0cc07@mail.gmail.com> References: <4EBDBF94-62BD-48E9-A262-A4E9E91249E4@gmail.com> <924f29280809220752i646b69e5u5455ac5426f0cc07@mail.gmail.com> Message-ID: <20080922165937.62377b74@mlejnas.priv.castalie.org> On Mon, 22 Sep 2008 10:52:42 -0400 "Jason Frisvold" wrote: > I'm not much up on DNSSEC, but don't you need to be using a resolver > that recognizes DNSSEC in order for this to be useful? You do -- and last time I checked few native resolvers actually did : glibc doesn't, and I'd be surprised if the Windows resolver does Simon From owenc at hubris.net Mon Sep 22 10:02:21 2008 From: owenc at hubris.net (Chris Owen) Date: Mon, 22 Sep 2008 10:02:21 -0500 Subject: hat tip to .gov hostmasters In-Reply-To: <20080922165937.62377b74@mlejnas.priv.castalie.org> References: <4EBDBF94-62BD-48E9-A262-A4E9E91249E4@gmail.com> <924f29280809220752i646b69e5u5455ac5426f0cc07@mail.gmail.com> <20080922165937.62377b74@mlejnas.priv.castalie.org> Message-ID: <869CC897-C081-4357-A27E-8412F7DC99BE@hubris.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sep 22, 2008, at 9:59 AM, Simon Vallet wrote: > On Mon, 22 Sep 2008 10:52:42 -0400 > "Jason Frisvold" wrote: > >> I'm not much up on DNSSEC, but don't you need to be using a resolver >> that recognizes DNSSEC in order for this to be useful? > > You do -- and last time I checked few native resolvers actually did : > glibc doesn't, and I'd be surprised if the Windows resolver does Chicken, meet egg. I think the point of the original post is that one end or the other has to start things. At least we have one US zone doing something on the server end of things. 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 iEYEARECAAYFAkjXs30ACgkQElUlCLUT2d0SfwCbB8FQ4izN061GoQQMl3fkq+NT ga0AoJnwGG8PfBs5PaziRB6m0NQBuZwc =68dm -----END PGP SIGNATURE----- From karnaugh at karnaugh.za.net Mon Sep 22 10:02:47 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Mon, 22 Sep 2008 17:02:47 +0200 Subject: hat tip to .gov hostmasters In-Reply-To: <82ljxkkz57.fsf@mid.bfk.de> References: <4EBDBF94-62BD-48E9-A262-A4E9E91249E4@gmail.com> <924f29280809220752i646b69e5u5455ac5426f0cc07@mail.gmail.com> <82ljxkkz57.fsf@mid.bfk.de> Message-ID: <48D7B397.3000909@karnaugh.za.net> Florian Weimer wrote: > * Jason Frisvold: > >> On Mon, Sep 22, 2008 at 10:34 AM, Scott Francis wrote: >>> nice to see a wholesale DNSSEC rollout underway (I must confess to being a >>> little surprised at the source, too!). Granted, it's a much more manageable >>> problem set than, say, .com - but if one US-controlled TLD can do it, hope >>> is buoyed for a .com rollout sooner rather than later (although probably not >>> much sooner :)). >> I'm not much up on DNSSEC, but don't you need to be using a resolver >> that recognizes DNSSEC in order for this to be useful? > > Correct, you need a validating, security-aware stub resolver, or the > ISP needs to validate the records for you. > In public space like .com, don't you need some kind of central trustworthy CA? From fweimer at bfk.de Mon Sep 22 10:09:33 2008 From: fweimer at bfk.de (Florian Weimer) Date: Mon, 22 Sep 2008 17:09:33 +0200 Subject: hat tip to .gov hostmasters In-Reply-To: <48D7B397.3000909@karnaugh.za.net> (Colin Alston's message of "Mon, 22 Sep 2008 17:02:47 +0200") References: <4EBDBF94-62BD-48E9-A262-A4E9E91249E4@gmail.com> <924f29280809220752i646b69e5u5455ac5426f0cc07@mail.gmail.com> <82ljxkkz57.fsf@mid.bfk.de> <48D7B397.3000909@karnaugh.za.net> Message-ID: <82bpygkyj6.fsf@mid.bfk.de> * Colin Alston: >> Correct, you need a validating, security-aware stub resolver, or the >> ISP needs to validate the records for you. > In public space like .com, don't you need some kind of central > trustworthy CA? No, why would you? You need to trust the zone operator, and you need some trustworthy channel to exchange trust anchors at one point in time (a significant improvement compared to classic DNS, where you need a trustworthy channel all the time). -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From nanog at castalie.org Mon Sep 22 10:10:29 2008 From: nanog at castalie.org (Simon Vallet) Date: Mon, 22 Sep 2008 17:10:29 +0200 Subject: hat tip to .gov hostmasters In-Reply-To: <869CC897-C081-4357-A27E-8412F7DC99BE@hubris.net> References: <4EBDBF94-62BD-48E9-A262-A4E9E91249E4@gmail.com> <924f29280809220752i646b69e5u5455ac5426f0cc07@mail.gmail.com> <20080922165937.62377b74@mlejnas.priv.castalie.org> <869CC897-C081-4357-A27E-8412F7DC99BE@hubris.net> Message-ID: <20080922171029.073a9570@mlejnas.priv.castalie.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 22 Sep 2008 10:02:21 -0500 Chris Owen wrote: > Chicken, meet egg. > > I think the point of the original post is that one end or the other > has to start things. At least we have one US zone doing something on > the server end of things. I totally agree on that, but wanted to point out that there still is some work be done. The folks at NLnet do have a nice DNSSEC implementation, though, as well as the BIND library. Simon -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkjXtWUACgkQccZs6oMJsYR5XQCbB6e92xTcaR2ijn0DcAALdswA 358AmQH36qg/fBRGxJIFS4Alm4sAKF9w =7JfR -----END PGP SIGNATURE----- From kmedcalf at dessus.com Mon Sep 22 10:11:40 2008 From: kmedcalf at dessus.com (Keith Medcalf) Date: Mon, 22 Sep 2008 11:11:40 -0400 Subject: hat tip to .gov hostmasters In-Reply-To: <82ljxkkz57.fsf@mid.bfk.de> Message-ID: <5e1ed4c17ecb92458fcc3ee097ea7638@mail.dessus.com> > Correct, you need a validating, security-aware stub resolver, or the > ISP needs to validate the records for you. That would defeat the entire purpose of using DNSSEC. In order for DNSSEC to actually provide any improvement in security whatsoever, the ROOT ZONE (.) needs to be signed, and every delegation up the chain needs to be signed. And EVERY resolver (whether recursive or local on host) needs to understand and enforce DNSSEC. If even one delegation is unsigned or even one resolver does not enforce DNSSEC, then, from an actual security perspective, you will be far worse off than you are now. Until such time as EVERY SINGLE DOMAIN including the root is signed and every single DNS Server and resolver (including the local host resolvers) understand and enforce DNSSEC you should realize that DNSSEC does nothing for you whatsoever except give the uneducated a false sense of "security". It is likely that IPv48 will be deployed long before DNSSEC is implemented. From fweimer at bfk.de Mon Sep 22 10:13:25 2008 From: fweimer at bfk.de (Florian Weimer) Date: Mon, 22 Sep 2008 17:13:25 +0200 Subject: hat tip to .gov hostmasters In-Reply-To: <20080922165937.62377b74@mlejnas.priv.castalie.org> (Simon Vallet's message of "Mon, 22 Sep 2008 16:59:37 +0200") References: <4EBDBF94-62BD-48E9-A262-A4E9E91249E4@gmail.com> <924f29280809220752i646b69e5u5455ac5426f0cc07@mail.gmail.com> <20080922165937.62377b74@mlejnas.priv.castalie.org> Message-ID: <827i94kycq.fsf@mid.bfk.de> * Simon Vallet: >> I'm not much up on DNSSEC, but don't you need to be using a resolver >> that recognizes DNSSEC in order for this to be useful? > > You do -- and last time I checked few native resolvers actually did : > glibc doesn't, and I'd be surprised if the Windows resolver does Windows doesn't. To my knowledge, there aren't any deployed valdiating, security-aware stub resolvers. Your best bet is to run BIND or Unbound locally with appropriate trust anchors, and use that as the system's resolver. With modern LRU-based caches which are efficient even at smallish sizes, this isn't much of a problem. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From marcus.sachs at verizon.com Mon Sep 22 10:16:20 2008 From: marcus.sachs at verizon.com (marcus.sachs at verizon.com) Date: Mon, 22 Sep 2008 11:16:20 -0400 Subject: hat tip to .gov hostmasters In-Reply-To: <82bpygkyj6.fsf@mid.bfk.de> References: <4EBDBF94-62BD-48E9-A262-A4E9E91249E4@gmail.com><924f29280809220752i646b69e5u5455ac5426f0cc07@mail.gmail.com><82ljxkkz57.fsf@mid.bfk.de> <48D7B397.3000909@karnaugh.za.net> <82bpygkyj6.fsf@mid.bfk.de> Message-ID: <6BCAB7B989C2EA4AAD36652C14D4FB4563512B@FHDP1CCMXCV02.us.one.verizon.com> DNSSEC is not a PKI. There are no CAs and no X.509 certificates. It's a chain of trust that can be validated using public/private key pairs. OK, that's oversimplification but you get the idea. While we wait for applications to become DNSSEC-aware, if your local DNS server can be trusted (a big "if" of course) then it can proxy the DNSSEC awareness for you. Since nearly everybody trusts a local DNS server to resolve queries, then making that server DNSSEC aware is an enormous step forward, even if the actual applications and operating systems on end-user computers are not fully DNSSEC-aware and won't be for many years to come. Marc -----Original Message----- From: Florian Weimer [mailto:fweimer at bfk.de] Sent: Monday, September 22, 2008 11:10 AM To: Colin Alston Cc: nanog at nanog.org Subject: Re: hat tip to .gov hostmasters * Colin Alston: >> Correct, you need a validating, security-aware stub resolver, or the >> ISP needs to validate the records for you. > In public space like .com, don't you need some kind of central > trustworthy CA? No, why would you? You need to trust the zone operator, and you need some trustworthy channel to exchange trust anchors at one point in time (a significant improvement compared to classic DNS, where you need a trustworthy channel all the time). -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From xenophage0 at gmail.com Mon Sep 22 10:16:12 2008 From: xenophage0 at gmail.com (Jason Frisvold) Date: Mon, 22 Sep 2008 11:16:12 -0400 Subject: hat tip to .gov hostmasters In-Reply-To: <869CC897-C081-4357-A27E-8412F7DC99BE@hubris.net> References: <4EBDBF94-62BD-48E9-A262-A4E9E91249E4@gmail.com> <924f29280809220752i646b69e5u5455ac5426f0cc07@mail.gmail.com> <20080922165937.62377b74@mlejnas.priv.castalie.org> <869CC897-C081-4357-A27E-8412F7DC99BE@hubris.net> Message-ID: <924f29280809220816h31c8b313o5aa4eae2482fa768@mail.gmail.com> On Mon, Sep 22, 2008 at 11:02 AM, Chris Owen wrote: > Chicken, meet egg. > > I think the point of the original post is that one end or the other has to > start things. At least we have one US zone doing something on the server > end of things. Oh, agreed, absolutely. And it's great to see. However, neither the slashdot blurb, nor the NetworkWorld article mention that without a valid resolver, there is no guarantee of security. Sure, they mention that vendors are rolling it out and that ISPs should be following suit, but no mention is made of the end-user's resolver at all... > Chris -- Jason 'XenoPhage' Frisvold XenoPhage0 at gmail.com http://blog.godshell.com From fweimer at bfk.de Mon Sep 22 10:20:18 2008 From: fweimer at bfk.de (Florian Weimer) Date: Mon, 22 Sep 2008 17:20:18 +0200 Subject: hat tip to .gov hostmasters In-Reply-To: <5e1ed4c17ecb92458fcc3ee097ea7638@mail.dessus.com> (Keith Medcalf's message of "Mon, 22 Sep 2008 11:11:40 -0400") References: <5e1ed4c17ecb92458fcc3ee097ea7638@mail.dessus.com> Message-ID: <82prmwjjgt.fsf@mid.bfk.de> * Keith Medcalf: >> Correct, you need a validating, security-aware stub resolver, or the >> ISP needs to validate the records for you. > > That would defeat the entire purpose of using DNSSEC. In order for >DNSSEC to actually provide any improvement in security whatsoever, >the ROOT ZONE (.) needs to be signed, and every delegation up the >chain needs to be signed. And EVERY resolver (whether recursive or >local on host) needs to understand and enforce DNSSEC. Either the resolver needs to enforce, or the host. It's not necessary to do both. It's also not strictly necessary that the root is signed, provided that there is some way to manage the trust anchors (either through software updates, like it is done for the browser CA list, or through regular DNS management at the ISP resolver). > If even one delegation is unsigned or even one resolver does not > enforce DNSSEC, then, from an actual security perspective, you will > be far worse off than you are now. Why? > Until such time as EVERY SINGLE DOMAIN including the root is signed > and every single DNS Server and resolver (including the local host > resolvers) understand and enforce DNSSEC you should realize that > DNSSEC does nothing for you whatsoever except give the uneducated a > false sense of "security". DNSSEC is totally invisible to the end user. There won't be any browser icon that says "it's okay to enter your PII here because the zone is DNSSEC-signed". It's purely an infrastructure measure, like physically securing your routers. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From bmanning at vacation.karoshi.com Mon Sep 22 10:19:46 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 22 Sep 2008 15:19:46 +0000 Subject: hat tip to .gov hostmasters In-Reply-To: <924f29280809220752i646b69e5u5455ac5426f0cc07@mail.gmail.com> References: <4EBDBF94-62BD-48E9-A262-A4E9E91249E4@gmail.com> <924f29280809220752i646b69e5u5455ac5426f0cc07@mail.gmail.com> Message-ID: <20080922151946.GA14460@vacation.karoshi.com.> On Mon, Sep 22, 2008 at 10:52:42AM -0400, Jason Frisvold wrote: > On Mon, Sep 22, 2008 at 10:34 AM, Scott Francis wrote: > > nice to see a wholesale DNSSEC rollout underway (I must confess to being a > > little surprised at the source, too!). Granted, it's a much more manageable > > problem set than, say, .com - but if one US-controlled TLD can do it, hope > > is buoyed for a .com rollout sooner rather than later (although probably not > > much sooner :)). > > I'm not much up on DNSSEC, but don't you need to be using a resolver > that recognizes DNSSEC in order for this to be useful? > > > /sf > > > -- > Jason 'XenoPhage' Frisvold > XenoPhage0 at gmail.com > http://blog.godshell.com yes and no. to fully trust the data from the servers you need three things: ) signed data (this is what .gov is doing) ) a validator in the end system (this is mostly missing/not configured today) ) accurate trust anchors from a couple of places in the DNS namespace ## however, if all you start with is signed data - it becomes possible to verify the source of the data - independently of inline DNS validation. e.g. you can - with a high degree of certainty, be assured that the root zone you load is really the ORSN root and not that flaky root from DoC/ICANN/VSGN... :) so "naked" signed data, in the absence of TA's or validators is still useful. ## you'll need a couple of these - and how you get them and keep them up to date is still a mostly unsolved operational problem. --bill From fweimer at bfk.de Mon Sep 22 10:24:00 2008 From: fweimer at bfk.de (Florian Weimer) Date: Mon, 22 Sep 2008 17:24:00 +0200 Subject: hat tip to .gov hostmasters In-Reply-To: <6BCAB7B989C2EA4AAD36652C14D4FB4563512B@FHDP1CCMXCV02.us.one.verizon.com> (marcus sachs's message of "Mon, 22 Sep 2008 11:16:20 -0400") References: <4EBDBF94-62BD-48E9-A262-A4E9E91249E4@gmail.com> <924f29280809220752i646b69e5u5455ac5426f0cc07@mail.gmail.com> <82ljxkkz57.fsf@mid.bfk.de> <48D7B397.3000909@karnaugh.za.net> <82bpygkyj6.fsf@mid.bfk.de> <6BCAB7B989C2EA4AAD36652C14D4FB4563512B@FHDP1CCMXCV02.us.one.verizon.com> Message-ID: <82ljxkjjan.fsf@mid.bfk.de> * marcus sachs: > While we wait for applications to become DNSSEC-aware, Uhm, applications shouldn't be DNSSEC-aware. Down that road lies madness. What should an end user do when the browser tells him, "Warning: Could not validate DNSSEC signature on www.example.com, signature has expired. Continue to connect?" -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From bmanning at vacation.karoshi.com Mon Sep 22 10:27:07 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 22 Sep 2008 15:27:07 +0000 Subject: hat tip to .gov hostmasters In-Reply-To: <5e1ed4c17ecb92458fcc3ee097ea7638@mail.dessus.com> References: <82ljxkkz57.fsf@mid.bfk.de> <5e1ed4c17ecb92458fcc3ee097ea7638@mail.dessus.com> Message-ID: <20080922152707.GB14460@vacation.karoshi.com.> On Mon, Sep 22, 2008 at 11:11:40AM -0400, Keith Medcalf wrote: > > > Correct, you need a validating, security-aware stub resolver, or the > > ISP needs to validate the records for you. > > That would defeat the entire purpose of using DNSSEC. In order for DNSSEC to actually provide any improvement in security whatsoever, the ROOT ZONE (.) needs to be signed, and every delegation up the chain needs to be signed. And EVERY resolver (whether recursive or local on host) needs to understand and enforce DNSSEC. er, no. the root zone does not need to be signed and not every delegation. and only the resolvers in the path from auth servers to validators need to ensure that the DNSSEC data is retained. if the only TA I have is for .SE (configured in my validator) and my resolver passes the DNSSEC data unchanged it received from the .SE servers, then I can securely trust the (short) validation chain when I look up axfr.se. even though -nothing else- is signed. > > If even one delegation is unsigned or even one resolver does not enforce DNSSEC, then, from an actual security perspective, you will be far worse off than you are now. depends on your POV of course... > Until such time as EVERY SINGLE DOMAIN including the root is signed and every single DNS Server and resolver (including the local host resolvers) understand and enforce DNSSEC you should realize that DNSSEC does nothing for you whatsoever except give the uneducated a false sense of "security". I think you have unrealistic expectations. Time will tell. > > It is likely that IPv48 will be deployed long before DNSSEC is implemented. --bill From bmanning at vacation.karoshi.com Mon Sep 22 10:30:44 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 22 Sep 2008 15:30:44 +0000 Subject: hat tip to .gov hostmasters In-Reply-To: <82ljxkjjan.fsf@mid.bfk.de> References: <4EBDBF94-62BD-48E9-A262-A4E9E91249E4@gmail.com> <924f29280809220752i646b69e5u5455ac5426f0cc07@mail.gmail.com> <82ljxkkz57.fsf@mid.bfk.de> <48D7B397.3000909@karnaugh.za.net> <82bpygkyj6.fsf@mid.bfk.de> <6BCAB7B989C2EA4AAD36652C14D4FB4563512B@FHDP1CCMXCV02.us.one.verizon.com> <82ljxkjjan.fsf@mid.bfk.de> Message-ID: <20080922153044.GC14460@vacation.karoshi.com.> On Mon, Sep 22, 2008 at 05:24:00PM +0200, Florian Weimer wrote: > * marcus sachs: > > > While we wait for applications to become DNSSEC-aware, > > Uhm, applications shouldn't be DNSSEC-aware. Down that road lies > madness. What should an end user do when the browser tells him, > "Warning: Could not validate DNSSEC signature on www.example.com, > signature has expired. Continue to connect?" > > -- > Florian Weimer actually, I am really hoping that at least one API is standardized so that applications can use DNSSEC data. We never finished the discussion on fail/open fail/closed wrt DNSSEC. --bill From mike at mtcc.com Mon Sep 22 10:42:58 2008 From: mike at mtcc.com (Michael Thomas) Date: Mon, 22 Sep 2008 08:42:58 -0700 Subject: hat tip to .gov hostmasters In-Reply-To: <924f29280809220816h31c8b313o5aa4eae2482fa768@mail.gmail.com> References: <4EBDBF94-62BD-48E9-A262-A4E9E91249E4@gmail.com> <924f29280809220752i646b69e5u5455ac5426f0cc07@mail.gmail.com> <20080922165937.62377b74@mlejnas.priv.castalie.org> <869CC897-C081-4357-A27E-8412F7DC99BE@hubris.net> <924f29280809220816h31c8b313o5aa4eae2482fa768@mail.gmail.com> Message-ID: <48D7BD02.6020208@mtcc.com> Jason Frisvold wrote: > On Mon, Sep 22, 2008 at 11:02 AM, Chris Owen wrote: > >> Chicken, meet egg. >> >> I think the point of the original post is that one end or the other has to >> start things. At least we have one US zone doing something on the server >> end of things. >> > > Oh, agreed, absolutely. And it's great to see. However, neither the > slashdot blurb, nor the NetworkWorld article mention that without a > valid resolver, there is no guarantee of security. Sure, they mention > that vendors are rolling it out and that ISPs should be following > suit, but no mention is made of the end-user's resolver at all... > I dunno, a few very strategically placed validating resolvers could subject a huge amount of DNS traffic to a much higher bar were the senders so inclined to sign their zones. But I tend to view these kinds of things much more from an "epidemiology" point of view: you don't have to have 100% eradication to control an epidemic. Same thing pretty much goes with internet based attacks, IMO: when the barrier is set sufficiently high in one area, attackers don't spend their entire time trying to break that barrier, they find the next lowest barrier and move on. Mike From jgoltz at mail.nih.gov Mon Sep 22 10:42:33 2008 From: jgoltz at mail.nih.gov (Goltz, Jim (NIH/CIT) [E]) Date: Mon, 22 Sep 2008 11:42:33 -0400 Subject: hat tip to .gov hostmasters In-Reply-To: <4EBDBF94-62BD-48E9-A262-A4E9E91249E4@gmail.com> References: <4EBDBF94-62BD-48E9-A262-A4E9E91249E4@gmail.com> Message-ID: > nice to see a wholesale DNSSEC rollout underway (I must confess to > being a little surprised at the source, too!). Granted, it's a much > more manageable problem set than, say, .com - but if one US-controlled > TLD can do it, hope is buoyed for a .com rollout sooner rather than > later (although probably not much sooner :)). It ain't done yet. I don't speak for the hostmasters of .gov or any subdomain thereof. But I'll believe it when I see it. Remember, they've also "mandated" IPv6 support on all backbones. -- Jim Goltz CIT/DCSS/HSB/ASIG 12/2216 From darkuncle at gmail.com Mon Sep 22 10:43:36 2008 From: darkuncle at gmail.com (Scott Francis) Date: Mon, 22 Sep 2008 08:43:36 -0700 Subject: hat tip to .gov hostmasters In-Reply-To: <924f29280809220816h31c8b313o5aa4eae2482fa768@mail.gmail.com> References: <4EBDBF94-62BD-48E9-A262-A4E9E91249E4@gmail.com> <924f29280809220752i646b69e5u5455ac5426f0cc07@mail.gmail.com> <20080922165937.62377b74@mlejnas.priv.castalie.org> <869CC897-C081-4357-A27E-8412F7DC99BE@hubris.net> <924f29280809220816h31c8b313o5aa4eae2482fa768@mail.gmail.com> Message-ID: <171423de0809220843l63ba41bfl487a51a5aa17013f@mail.gmail.com> On Mon, Sep 22, 2008 at 8:16 AM, Jason Frisvold wrote: > On Mon, Sep 22, 2008 at 11:02 AM, Chris Owen wrote: >> Chicken, meet egg. >> >> I think the point of the original post is that one end or the other has to >> start things. At least we have one US zone doing something on the server >> end of things. > > Oh, agreed, absolutely. And it's great to see. However, neither the > slashdot blurb, nor the NetworkWorld article mention that without a > valid resolver, there is no guarantee of security. Sure, they mention > that vendors are rolling it out and that ISPs should be following > suit, but no mention is made of the end-user's resolver at all... the NetworkWorld article (in the printer-friendly version, at least) has a little table that shows the DNSSEC status of the major vendors. And support in the resolver library is not strictly necessary, as long as you trust _your_ (or your ISP's) nameservers. (not to say that it isn't a good idea, just that it's not requirement for initial rollout.) -- darkuncle@{gmail.com,darkuncle.net} || 0x5537F527 http://darkuncle.net/pubkey.asc for public key From kmedcalf at dessus.com Mon Sep 22 10:49:50 2008 From: kmedcalf at dessus.com (Keith Medcalf) Date: Mon, 22 Sep 2008 11:49:50 -0400 Subject: hat tip to .gov hostmasters In-Reply-To: <82prmwjjgt.fsf@mid.bfk.de> Message-ID: <81434005e9f40a458bb39ab7d95910c1@mail.dessus.com> > > That would defeat the entire purpose of using DNSSEC. In order for > >DNSSEC to actually provide any improvement in security whatsoever, > >the ROOT ZONE (.) needs to be signed, and every delegation up the > >chain needs to be signed. And EVERY resolver (whether recursive or > >local on host) needs to understand and enforce DNSSEC. > Either the resolver needs to enforce, or the host. It's not necessary > to do both. It's also not strictly necessary that the root is signed, > provided that there is some way to manage the trust anchors (either > through software updates, like it is done for the browser CA list, or > through regular DNS management at the ISP resolver). > > If even one delegation is unsigned or even one resolver does not > > enforce DNSSEC, then, from an actual security perspective, you will > > be far worse off than you are now. > Why? If the local resolver does not perform DNSSEC validation, then I cannot validate that the response is correct. I certainly do not trust anyone else to verify that the information is correct and then, without any possible verification, simply believe that the third party did the validation. In fact, I have no way of knowing that the response even came from the "ISP" at all unless the client resolver supports DNSSEC. Just because YOU check the digital signature on an email and forward that email to me (either with or without the signature data), if I do not have the capability to verify the signature myself, I sure as hell am not going to trust your mere say-so that the signature is valid! If I cannot authenticate the data myself, then it is simply untrusted and untrustworthy -- exactly the same as it is now. The real problem is that the clueless (with a hidden self-aggrandizing and a primary motive of "lining my pockets with other peoples money" will convince the ignorant that it is more secure. Sort of like banning toothpaste from carry-on baggage "impoves" the security of air travel, when in fact it does nothing more than help the idiots in charge of promulgating such polies to rip off (rob) other people of their money by deliberate fraud and misrepresentation. > > Until such time as EVERY SINGLE DOMAIN including the root is signed > > and every single DNS Server and resolver (including the local host > > resolvers) understand and enforce DNSSEC you should realize that > > DNSSEC does nothing for you whatsoever except give the uneducated a > > false sense of "security". > DNSSEC is totally invisible to the end user. There won't be any > browser icon that says "it's okay to enter your PII here because the > zone is DNSSEC-signed". It's purely an infrastructure measure, like > physically securing your routers. The end-stage is secure only if at that stage you also set all DNS infrastructure to refuse to talk to any DNS client/server/resolver that DOES NOT validate and enforce DNSSEC. Up until that point in time, there is NO CHANGE in the security posture from what we have today with no DNSSEC whatsoever. To hold forth otherwise is to participate in deliberate fraud and misrepresentation of material facts. From darkuncle at gmail.com Mon Sep 22 10:54:16 2008 From: darkuncle at gmail.com (Scott Francis) Date: Mon, 22 Sep 2008 08:54:16 -0700 Subject: hat tip to .gov hostmasters In-Reply-To: <81434005e9f40a458bb39ab7d95910c1@mail.dessus.com> References: <82prmwjjgt.fsf@mid.bfk.de> <81434005e9f40a458bb39ab7d95910c1@mail.dessus.com> Message-ID: <171423de0809220854o50fe29acyb3a62fcad7a8e76c@mail.gmail.com> On Mon, Sep 22, 2008 at 8:49 AM, Keith Medcalf wrote: >> > If even one delegation is unsigned or even one resolver does not >> > enforce DNSSEC, then, from an actual security perspective, you will >> > be far worse off than you are now. > >> Why? > > If the local resolver does not perform DNSSEC validation, then I cannot validate that the response is correct. > I certainly do not trust anyone else to verify that the information is correct and then, without any possible verification, > simply believe that the third party did the validation. In fact, I have no way of knowing that the response even came > from the "ISP" at all unless the client resolver supports DNSSEC. > > Just because YOU check the digital signature on an email and forward that email to me (either with or without the > signature data), if I do not have the capability to verify the signature myself, I sure as hell am not going to trust your > mere say-so that the signature is valid! > > If I cannot authenticate the data myself, then it is simply untrusted and untrustworthy -- exactly the same as it is now. so I guess PGP web of trust is right out, then? (in the real world, we rarely get boolean values on security questions) -- darkuncle@{gmail.com,darkuncle.net} || 0x5537F527 http://darkuncle.net/pubkey.asc for public key From pauldotwall at gmail.com Mon Sep 22 11:07:40 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Mon, 22 Sep 2008 12:07:40 -0400 Subject: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <514811.97087.qm@web38906.mail.mud.yahoo.com> References: <514811.97087.qm@web38906.mail.mud.yahoo.com> Message-ID: <620fd17c0809220907q126a9e52hfd4527eafa44a285@mail.gmail.com> Emil, If you've actually shut off the RBN, you should have no problem finding some new transit to turn up, right? We're in a buyer's market, and there are dozens of vendors on-net at 200 Paul who'd love a piece of your business. Drive Slow, Paul Wall On Sun, Sep 21, 2008 at 3:20 PM, Emil Kacperski wrote: > Hello, > > It's true that David from PIE disconnected our link approx 9pm or so yesterday. Things were going perfect, no complaints for a few weeks now. The only thing I believe is that NTT gave lots of pressure to PIE. For some unknown reason when I tried to reach out to the security guy at NTT he basically said our contract is with PIE. > > So in a time like this you really get to know who your friends are and who should be avoided. > > Onward and upward! What doesn't kill you only makes you stronger ;-). Just feel bad for the customers for which I am truly sorry for right now ;-(. > > Thanks! > > Contact: Emil Kacperski > > Company: Intercage Inc. - Atrivo > > Dedicated Servers > > San Francisco Datacenter > > E-Mail: emil at intercage.com > > Phone: 925-550-3947 > > ICQ: 23531098 > > > > From kmedcalf at dessus.com Mon Sep 22 11:14:53 2008 From: kmedcalf at dessus.com (Keith Medcalf) Date: Mon, 22 Sep 2008 12:14:53 -0400 Subject: hat tip to .gov hostmasters In-Reply-To: <171423de0809220854o50fe29acyb3a62fcad7a8e76c@mail.gmail.com> Message-ID: <138baa54d7b92040b7ee92498a413f86@mail.dessus.com> > > Just because YOU check the digital signature on an email > and forward that email to me (either with or without the > > signature data), if I do not have the capability to verify > the signature myself, I sure as hell am not going to trust your > > mere say-so that the signature is valid! > > If I cannot authenticate the data myself, then it is simply > untrusted and untrustworthy -- exactly the same as it is now. > so I guess PGP web of trust is right out, then? You are confusing "validating signature" with "validating the holder of the keying material and the authorization of the holder to deploy it to create a non-repudiable signature", which are two entirely different and completely unreleated things. (This is quite common by the way, so maybe you can be excused your confusion). If there is a piece of data X signed with a cryptographically generated signature, and *I* verify that indeed the signature is valid, then the signature is valid -- that is, I can say with 100% absolute certainty that specific bit of keying material was used to generate a signature on something and that I have another bit of keying material which validates that signature. I am assured with very high certainty that THE DATA WAS SIGNED BY THE POSSESSOR OF THE SECRET KEYING MATERIAL. Nothing more can be determined from the signature. You now want to confuse the issue by associating the "keying material" with a "person" or "entity". That problem is entirely outside the purview of the exercize and completely irrelevant. (I certainly do not "trust" that any certificate issued by a so-called Certificate Authority (other than myself) was issued to the entity it is purported to be issued to, nor that the key is properly kept secret, nor anything else. The mathematical validity of the signature is beyond question. Associating that signature to anything other than a mere statement that "this data was signed by the possessor of the secret key corresponding to the public key that I have" is a personal judgement call. From Ed.Lewis at neustar.biz Mon Sep 22 11:06:57 2008 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 22 Sep 2008 12:06:57 -0400 Subject: hat tip to .gov hostmasters In-Reply-To: <20080922153044.GC14460@vacation.karoshi.com.> References: <4EBDBF94-62BD-48E9-A262-A4E9E91249E4@gmail.com> <924f29280809220752i646b69e5u5455ac5426f0cc07@mail.gmail.com> <82ljxkkz57.fsf@mid.bfk.de> <48D7B397.3000909@karnaugh.za.net> <82bpygkyj6.fsf@mid.bfk.de> <6BCAB7B989C2EA4AAD36652C14D4FB4563512B@FHDP1CCMXCV02.us.one.verizon.com> <82ljxkjjan.fsf@mid.bfk.de> <20080922153044.GC14460@vacation.karoshi.com.> Message-ID: At 15:30 +0000 9/22/08, bmanning at vacation.karoshi.com wrote: > data. We never finished the discussion on fail/open > fail/closed wrt DNSSEC. And I'd bet a dollar we never will finish that discussion. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. From bmanning at vacation.karoshi.com Mon Sep 22 11:22:11 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 22 Sep 2008 16:22:11 +0000 Subject: hat tip to .gov hostmasters In-Reply-To: <81434005e9f40a458bb39ab7d95910c1@mail.dessus.com> References: <82prmwjjgt.fsf@mid.bfk.de> <81434005e9f40a458bb39ab7d95910c1@mail.dessus.com> Message-ID: <20080922162211.GA15144@vacation.karoshi.com.> > > The end-stage is secure only if at that stage you also set all DNS infrastructure to refuse to talk to any DNS client/server/resolver that DOES NOT validate and enforce DNSSEC. Up until that point in time, there is NO CHANGE in the security posture from what we have today with no DNSSEC whatsoever. > > To hold forth otherwise is to participate in deliberate fraud and misrepresentation of material facts. > > so you are a "fail/closed" proponent. a fail/open approach would have failure of DNSSEC-based validation behave just like the DNS of today. The use of Trust Anchors and signed "islands" allow one to find "golden threads" of validated chains in the dns fabric ... e.g. incremental rollout vs flag day. --bill From bmanning at vacation.karoshi.com Mon Sep 22 11:23:11 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 22 Sep 2008 16:23:11 +0000 Subject: hat tip to .gov hostmasters In-Reply-To: References: <4EBDBF94-62BD-48E9-A262-A4E9E91249E4@gmail.com> <924f29280809220752i646b69e5u5455ac5426f0cc07@mail.gmail.com> <82ljxkkz57.fsf@mid.bfk.de> <48D7B397.3000909@karnaugh.za.net> <82bpygkyj6.fsf@mid.bfk.de> <6BCAB7B989C2EA4AAD36652C14D4FB4563512B@FHDP1CCMXCV02.us.one.verizon.com> <82ljxkjjan.fsf@mid.bfk.de> <20080922153044.GC14460@vacation.karoshi.com.> Message-ID: <20080922162311.GB15144@vacation.karoshi.com.> On Mon, Sep 22, 2008 at 12:06:57PM -0400, Edward Lewis wrote: > At 15:30 +0000 9/22/08, bmanning at vacation.karoshi.com wrote: > > > data. We never finished the discussion on fail/open > > fail/closed wrt DNSSEC. > > And I'd bet a dollar we never will finish that discussion. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-571-434-5468 > NeuStar > > Never confuse activity with progress. Activity pays more. taken. (never is a -very- long time) --bill From bmanning at vacation.karoshi.com Mon Sep 22 11:27:25 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 22 Sep 2008 16:27:25 +0000 Subject: hat tip to .gov hostmasters In-Reply-To: <138baa54d7b92040b7ee92498a413f86@mail.dessus.com> References: <171423de0809220854o50fe29acyb3a62fcad7a8e76c@mail.gmail.com> <138baa54d7b92040b7ee92498a413f86@mail.dessus.com> Message-ID: <20080922162725.GC15144@vacation.karoshi.com.> On Mon, Sep 22, 2008 at 12:14:53PM -0400, Keith Medcalf wrote: > > > > If I cannot authenticate the data myself, then it is simply > > untrusted and untrustworthy -- exactly the same as it is now. > > > so I guess PGP web of trust is right out, then? > [elided] > > If there is a piece of data X signed with a cryptographically generated signature, and *I* verify that indeed the signature is valid, then the signature is valid -- that is, I can say with 100% absolute certainty that specific bit of keying material was used to generate a signature on something and that I have another bit of keying material which validates that signature. I am assured with very high certainty that THE DATA WAS SIGNED BY THE POSSESSOR OF THE SECRET KEYING MATERIAL. > > Nothing more can be determined from the signature. > let me understand this ... your use of the pronoun "I" in these contexts is in reference to your corporal being i.e. meatspace and not a software application running on some computer. --bill From oberman at es.net Mon Sep 22 11:53:56 2008 From: oberman at es.net (Kevin Oberman) Date: Mon, 22 Sep 2008 09:53:56 -0700 Subject: hat tip to .gov hostmasters In-Reply-To: Your message of "Mon, 22 Sep 2008 11:42:33 EDT." Message-ID: <20080922165356.ECDAE4500E@ptavv.es.net> > Date: Mon, 22 Sep 2008 11:42:33 -0400 > From: "Goltz, Jim (NIH/CIT) [E]" > > > nice to see a wholesale DNSSEC rollout underway (I must confess to > > being a little surprised at the source, too!). Granted, it's a much > > more manageable problem set than, say, .com - but if one US-controlled > > TLD can do it, hope is buoyed for a .com rollout sooner rather than > > later (although probably not much sooner :)). > > It ain't done yet. > > I don't speak for the hostmasters of .gov or any subdomain thereof. > But I'll believe it when I see it. I am pretty sure that you will see it. Unlike things like the IPv6 requirement, there are no waivers available for this. '.gov' must be signed early next year and all zones delegated from the '.gov' GTLD must be signed in early 2010. I doubt that many will sign until '.gov' is signed, so you won't see much change for a few months. Now, if the DOC people responsible for root would just catch a clue, we could get that signed and have DNSSEC actually usable (except for Mr. Metcalf) in a significant part of the US network before I retire. > Remember, they've also "mandated" IPv6 support on all backbones. Yes, and the goal, relatively insignificant that it was, was met. It was not a requirement that anyone actually use IPv6, only that the agency backbone networks be able to carry IPv6. In fact, the wording was such that doing proper routing was not even really needed. Our backbone has offered IPv6 as a production service since 2002, so it was a non-effort for us. Most other agency backbones were pretty trivial to make "IPv6 capable". The problem is that only the backbone currently needs IPv6. No facility network or end host needs it, No network service needs it. No IPv6 packets, even routing updates, need to be delivered in any useful way. It was a pretty trivial goal and was met with very little effort. -- 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 drc at virtualized.org Mon Sep 22 12:05:42 2008 From: drc at virtualized.org (David Conrad) Date: Mon, 22 Sep 2008 10:05:42 -0700 Subject: hat tip to .gov hostmasters In-Reply-To: <82ljxkkz57.fsf@mid.bfk.de> References: <4EBDBF94-62BD-48E9-A262-A4E9E91249E4@gmail.com> <924f29280809220752i646b69e5u5455ac5426f0cc07@mail.gmail.com> <82ljxkkz57.fsf@mid.bfk.de> Message-ID: <3CDAE586-5FDA-4932-8250-756BB9F64F10@virtualized.org> On Sep 22, 2008, at 7:56 AM, Florian Weimer wrote: >> I'm not much up on DNSSEC, but don't you need to be using a resolver >> that recognizes DNSSEC in order for this to be useful? Yes, and you also need the trust anchors for the zones you want to validate configured. > Correct, you need a validating, security-aware stub resolver, or the > ISP needs to validate the records for you. Slight clarification: you need a validating, security-aware resolver, whether that resolver is local (e.g., running on the same machine issuing the DNS queries) or remote (e.g., your ISP's resolver). Note that, for good or ill, you are trusting the operator of the resolver and the communication channel between the resolver and the application making the DNS requests. A validating, security-aware _stub_ resolver, typically linked into the program issuing the DNS requests and thus would be the ultimate in 'local', would have the ability to validate the response and supply feedback to the application with minimum vulnerability to MITM attacks. The downside is the added complexity of the code to the validation and to handle validation failures. Regards, -drc From drc at virtualized.org Mon Sep 22 12:16:09 2008 From: drc at virtualized.org (David Conrad) Date: Mon, 22 Sep 2008 10:16:09 -0700 Subject: hat tip to .gov hostmasters In-Reply-To: <5e1ed4c17ecb92458fcc3ee097ea7638@mail.dessus.com> References: <5e1ed4c17ecb92458fcc3ee097ea7638@mail.dessus.com> Message-ID: On Sep 22, 2008, at 8:11 AM, Keith Medcalf wrote: >> Correct, you need a validating, security-aware stub resolver, or the >> ISP needs to validate the records for you. > > That would defeat the entire purpose of using DNSSEC. In order for > DNSSEC to actually provide any improvement in security whatsoever, > the ROOT ZONE (.) needs to be signed, and every delegation up the > chain needs to be signed. The root does not need to be signed to provide security improvement. If you have configured the (say) .SE trust anchor in your validating resolver, you greatly reduce the chances that any lookup for a name in .SE can be spoofed. The downside of not having the root signed is that you need to maintain multiple trust anchors. > And EVERY resolver (whether recursive or local on host) needs to > understand and enforce DNSSEC. I personally believe it is more-or-less safe to trust communications local to the machine. As such, running a validating resolver on your local host would suffice. Having a stub resolver also validate in this scenario would be overkill. > If even one delegation is unsigned or even one resolver does not > enforce DNSSEC, then, from an actual security perspective, you will > be far worse off than you are now. In what way? I'm running a validating resolver on my laptop (using the signed root zone and trust anchor available from ns.iana.org so I only have to deal with one trust anchor). If someone tries to spoof a name in the root, .SE, .BG, .PR, .BR, .CZ, their efforts will fail. How is this worse off than before I configured my resolver? > Until such time as EVERY SINGLE DOMAIN including the root is signed > and every single DNS Server and resolver (including the local host > resolvers) understand and enforce DNSSEC you should realize that > DNSSEC does nothing for you whatsoever except give the uneducated a > false sense of "security". If this were true, DNSSEC would be a complete waste of time. Fortunately, it isn't true. Regards, -drc From stephen at sprunk.org Mon Sep 22 12:50:45 2008 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 22 Sep 2008 12:50:45 -0500 Subject: hat tip to .gov hostmasters In-Reply-To: <20080922165356.ECDAE4500E@ptavv.es.net> References: <20080922165356.ECDAE4500E@ptavv.es.net> Message-ID: <48D7DAF5.2090309@sprunk.org> Kevin Oberman wrote: >> Date: Mon, 22 Sep 2008 11:42:33 -0400 >> From: "Goltz, Jim (NIH/CIT) [E]" >> >> Remember, they've also "mandated" IPv6 support on all backbones. >> > > Yes, and the goal, relatively insignificant that it was, was met. It was not a requirement that anyone actually use IPv6, only that the agency backbone networks be able to carry IPv6. In fact, the wording was such that doing proper routing was not even really needed. > > Our backbone has offered IPv6 as a production service since 2002, so it was a non-effort for us. Most other agency backbones were pretty trivial to make "IPv6 capable". > > The problem is that only the backbone currently needs IPv6. No facility network or end host needs it, No network service needs it. No IPv6 packets, even routing updates, need to be delivered in any useful way. It was a pretty trivial goal and was met with very little effort. > They mandated that all products, not just hardware, support IPv6. However, all that the requirement turned out to be, in practice, is that all products be "software upgradeable" to IPv6. My employer is still selling stuff by the truckload to the USG because the hardware itself is "IPv6 capable" (just like it's OSI or DECnet "capable"), but we haven't written a single line of IPv6 code yet because customers aren't actually demanding it and we have other, more profitable, things to spend developers' limited time on. For vendors whose hardware needs to change for IPv4, like core routers, this is a big deal; for the rest of us, it was a non-event once we read the fine print. S From bonomi at mail.r-bonomi.com Mon Sep 22 13:21:49 2008 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Mon, 22 Sep 2008 13:21:49 -0500 (CDT) Subject: hat tip to .gov hostmasters Message-ID: <200809221821.m8MILnni014933@mail.r-bonomi.com> > Subject: RE: hat tip to .gov hostmasters > Date: Mon, 22 Sep 2008 11:49:50 -0400 > From: "Keith Medcalf" > > If I cannot authenticate the data myself, then it is simply untrusted and u= > ntrustworthy -- exactly the same as it is now. "Speak for yourself, John" applies. In the real world, there are cases where data that one is unable to authenticate by ones self *is* treated as fully trusted. Because someone with the authority to declare it to be that, by fiat, has done so. There may be a common "chain of command", and someone higher in the chain has declared that various inferiors "shall"(i.e. 'must') trust the work of other inferiors within the organization, for example. Or, it may be a contractually-delegated trust. Or, any of a number of other possibilities. Admittedly, in any of those scenarios, the 'strength' of trust is somewhat weaker than if it was self-verified, but it _is_ "far above" your claim of 'untrusted and untrustworthy'. > The end-stage is secure only if at that stage you also set all DNS infrastr= > ucture to refuse to talk to any DNS client/server/resolver that DOES NOT va= > lidate and enforce DNSSEC. Up until that point in time, there is NO CHANGE= > in the security posture from what we have today with no DNSSEC whatsoever. FALSE TO FACT. One does not have a _guarantee_ of 'accurate' data without end-to-end enforcement, this is true. Even _with_ end-to-end DNSSEC enforcement, one does not have such a guarantee. All it accomplishes is to make the insertion of bogus data harder. Not 'impossible', just 'harder'. If a local non-DNSSEC resolver consults _only_ a DNSSEC-aware server on an immediately adjacent network, it takes only a moderate 'extension of trust' to (a) the local network operator, (b) the adjacent network operator, and (c) the DNSSEC-aware server operator, to have a "reasonable degree" of trust in the accuracy of the data the local reslover has. This 'trust' involves the physical integrity of the networks -- that a host on -those- networks will not be allowed to spoof a source address of the DNSSEC-aware server; and the use of ingress-filtering on _source_ addresses -- to prevent any 'external' network/machine from spoofing it either. Beyond that, it is just a matter of 'trusting' a proper implementation on the server itself. _IF_ the anti-spoofing provisions are in place, and 'downstream' (non-aware) DNS resolvers (which consult -only- the 'aware' server) are under the same administrative control as the DNSSEC-aware one, *THEN* there is zero effective difference in the trust level for an answer obtained from the 'non-aware' system as one obtained from the 'aware' one. > To hold forth otherwise is to participate in deliberate fraud and misrepres= > entation of material facts. This really sounds like someone who has a financial interest in promulgating FUD. From James.R.Lindley at irs.gov Mon Sep 22 13:50:53 2008 From: James.R.Lindley at irs.gov (Lindley James R) Date: Mon, 22 Sep 2008 14:50:53 -0400 Subject: hat tip to .gov hostmasters In-Reply-To: <20080922165356.ECDAE4500E@ptavv.es.net> References: Your message of "Mon, 22 Sep 2008 11:42:33 EDT." <20080922165356.ECDAE4500E@ptavv.es.net> Message-ID: <64CB1CAFF7F54943AC711BFA52C54B7703D4B04D@NCT0010CP3MB01.ds.irsnet.gov> To digress on IPv6 momentarily. The airline magazine engineering memorandum* from OMB left two terms undefined in the mandate; "backbone network" and "IPv6 compatible." The Intra-agency IPv6 Federal Working Group wisely defined "backbone network" as (paraphrasing) the wire exiting the first publicly-reachable network perimeter router and entering the router next in the line of traffic and all devices attached to that wire between those two points as follows: {Internet}->|router|<-connecting wire---IPV6-[firewall, IDS, etc.]-IPV6--connecting wire->|next router in line|->NO IPV6-----... NIST is still working on "compatible." *Airline Magazine Engineering Memorandum: a mandate issued by an executive who can. The memorandum has four characteristics; 1) It mandates a technology not well understood by either the issuer or the recipient of the memo, 2) it sets a date certain by which the technology must be implemented, 3) it provides no funding, and 4, it contains one or more undefined terms whose exact meanings are absolutely crucial to actual implementation of the mandate. Source of the inspiration that originally convinced the issuing executive that they actually understood the scope and technology of the mandate is inherent in the title of this paragraph. JimL James R Lindley Senior Computer Engineer Advanced Technical Analysis Team IT Security Architecture and Engineering Internal Revenue Service An unquenchable thirst for Pierian waters. -----Original Message----- From: Kevin Oberman [mailto:oberman at es.net] Sent: Monday, September 22, 2008 12:54 To: Goltz, Jim (NIH/CIT) [E] Cc: nanog at nanog.org Subject: Re: hat tip to .gov hostmasters > Date: Mon, 22 Sep 2008 11:42:33 -0400 > From: "Goltz, Jim (NIH/CIT) [E]" > > > nice to see a wholesale DNSSEC rollout underway (I must confess to > > being a little surprised at the source, too!). Granted, it's a much > > more manageable problem set than, say, .com - but if one > > US-controlled TLD can do it, hope is buoyed for a .com rollout > > sooner rather than later (although probably not much sooner :)). > > It ain't done yet. > > I don't speak for the hostmasters of .gov or any subdomain thereof. > But I'll believe it when I see it. I am pretty sure that you will see it. Unlike things like the IPv6 requirement, there are no waivers available for this. '.gov' must be signed early next year and all zones delegated from the '.gov' GTLD must be signed in early 2010. I doubt that many will sign until '.gov' is signed, so you won't see much change for a few months. Now, if the DOC people responsible for root would just catch a clue, we could get that signed and have DNSSEC actually usable (except for Mr. Metcalf) in a significant part of the US network before I retire. > Remember, they've also "mandated" IPv6 support on all backbones. Yes, and the goal, relatively insignificant that it was, was met. It was not a requirement that anyone actually use IPv6, only that the agency backbone networks be able to carry IPv6. In fact, the wording was such that doing proper routing was not even really needed. Our backbone has offered IPv6 as a production service since 2002, so it was a non-effort for us. Most other agency backbones were pretty trivial to make "IPv6 capable". The problem is that only the backbone currently needs IPv6. No facility network or end host needs it, No network service needs it. No IPv6 packets, even routing updates, need to be delivered in any useful way. It was a pretty trivial goal and was met with very little effort. -- 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 jabley at hopcount.ca Mon Sep 22 14:01:35 2008 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 22 Sep 2008 15:01:35 -0400 Subject: favourite XFP supplier? Message-ID: Hi all, Anybody have a preferred supplier for 10GE XFPs, multimode and singlemode? These are to be installed in Force10 and Juniper hardware in Toronto, so a Canadian supplier would be fabulous although I won't hold my breath. Joe From tsparks at appliedops.net Mon Sep 22 15:33:31 2008 From: tsparks at appliedops.net (Tom Sparks (Applied Operations)) Date: Mon, 22 Sep 2008 13:33:31 -0700 Subject: Atrivo/Intercage Message-ID: <20080922203331.GA57011@web1.wotanworks.net> Just to add my $0.02 to this discussion and a disclaimer - I've known Emil for years, I've seen his shop and even the controversy. 200 Paul is a small community, and most of the folks in there know eachother, I've been in there since 2001 or so. Intercage is not a big shop, there are very few people involved in running it and I have a very hard time believing the accusations made by some of the folks around. I also don't believe Intercage was complicit in any net-crime; Thats not to say it didn't exist, but more along the lines of they got lost in the noise of running a business. I'd guess that given the server volume they've got, abuse emails are less than one percent of all the email they get in a week. From what I've seen, the bulk of their customer base is webhosters, Unix Shell providers and some video/audio streamers. Were I to venture a guess on the number of folks reselling those webservers, its probably on the order of thousands... Any time I've had an issue with one of Atrivo's customers, it only took one email to get it dealt with, or I got Emil on IM or on the phone and it was taken care of. My experience with being on the other end of abuse@, I'd say a good 60-75% of the complaints I saw coming in were bogus. Either people complaining about their ZoneAlarm's going off, people complaining about bounced emails with spam and a bunch of automated stuff that was always wrong. The legit complaints were not always easy to deal with either since a good 20-30% of them were unclear on what was actually wrong until you spent some time digging. Basically is what it boils down to for me - its easy to blame an NSP/ISP/Hoster for what their clients do, it takes real dedication to find out whats *actually* going on. -- Tom Sparks (415) 367-7328x1001 From drew.linsalata at gmail.com Mon Sep 22 15:48:16 2008 From: drew.linsalata at gmail.com (Drew Linsalata) Date: Mon, 22 Sep 2008 16:48:16 -0400 Subject: Atrivo/Intercage In-Reply-To: <20080922203331.GA57011@web1.wotanworks.net> References: <20080922203331.GA57011@web1.wotanworks.net> Message-ID: On Sep 22, 2008, at 4:33 PM, Tom Sparks (Applied Operations) wrote: > > Intercage is not a big shop, there are very few people involved in > running > it I have no dog in this fight, but I would comment on the "small shop" issue as it relates to handling abuse complaints. I own a small colo/hosting shop too. We don't have many employees. If we had to deal with so many abuse complaints that things were "getting lost in the noise", I'd have to seriously examine my AUP and associated enforcement policies, add staff to handle abuse issues, or both. Being small isn't an excuse. In fact, a small shop that runs a clean network should be far better at handling abuse issues than the larger players could ever hope to be. From patrick at ianai.net Mon Sep 22 15:52:28 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 22 Sep 2008 16:52:28 -0400 Subject: Atrivo/Intercage In-Reply-To: <20080922203331.GA57011@web1.wotanworks.net> References: <20080922203331.GA57011@web1.wotanworks.net> Message-ID: <17145F8C-7A39-40BE-AB4C-E9DC445D3697@ianai.net> On Sep 22, 2008, at 4:33 PM, Tom Sparks (Applied Operations) wrote: > Basically is what it boils down to for me - its easy to blame > an NSP/ISP/Hoster for what their clients do, it takes real > dedication to > find out whats *actually* going on. Tom, Atrivo is not just a spammer, and Intercage has _not_ "taken care of" problems - unless you count moving IP addresses around as "taking care of" things. I'm sure the people downloading child pr0n or hosting virus / C&C servers were very inconvenienced from having to change a hostname. Pardon me if I am incredulous. And not because we were not dedicated in trying to find out what was *actually* going on. Try reading up on your friend before accusing the community of not doing due diligence. And don't give me any BS about not reading his abuse@ mail. Eventually ignorance (willful ignorance?) in the service of evil becomes indistinguishable from malice. Basically, THAT is what it boils down to for me, and apparently everyone else as well. -- TTFN, patrick From tsparks at appliedops.net Mon Sep 22 15:53:43 2008 From: tsparks at appliedops.net (Tom Sparks (Applied Operations)) Date: Mon, 22 Sep 2008 13:53:43 -0700 Subject: Atrivo/Intercage In-Reply-To: References: <20080922203331.GA57011@web1.wotanworks.net> Message-ID: <20080922205343.GJ35551@web1.wotanworks.net> On Mon, Sep 22, 2008 at 04:48:16PM -0400, Drew Linsalata wrote: > I have no dog in this fight, but I would comment on the "small shop" > issue as it relates to handling abuse complaints. > > I own a small colo/hosting shop too. We don't have many employees. > If we had to deal with so many abuse complaints that things were > "getting lost in the noise" Perhaps I should clarify - Abuse complaints being a small percentage of normal requests for service (IE: I need a new hdd, an OS reinstalled) I would agree that anyone beseiged in abuse requests should take a machete to the offending customer's cables :) -- Tom Sparks (415) 367-7328x1001 From morrowc.lists at gmail.com Mon Sep 22 16:17:42 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 22 Sep 2008 17:17:42 -0400 Subject: Atrivo/Intercage In-Reply-To: <20080922205343.GJ35551@web1.wotanworks.net> References: <20080922203331.GA57011@web1.wotanworks.net> <20080922205343.GJ35551@web1.wotanworks.net> Message-ID: <75cb24520809221417x2dc2b5afqf6345deef4b9ab72@mail.gmail.com> So... apparently AS27595 is back on the air, with aspath's like: 6461 23342 27595 6539 23342 27595 8075 23342 27595 23342 == UnitedLayer, Tom isn't that you or is that another Tom I'm remembering? -Chris From morrowc.lists at gmail.com Mon Sep 22 16:25:39 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 22 Sep 2008 17:25:39 -0400 Subject: Atrivo/Intercage In-Reply-To: <75cb24520809221417x2dc2b5afqf6345deef4b9ab72@mail.gmail.com> References: <20080922203331.GA57011@web1.wotanworks.net> <20080922205343.GJ35551@web1.wotanworks.net> <75cb24520809221417x2dc2b5afqf6345deef4b9ab72@mail.gmail.com> Message-ID: <75cb24520809221425x21e0c884ld9aa83bb40f9b653@mail.gmail.com> On Mon, Sep 22, 2008 at 5:17 PM, Christopher Morrow wrote: > So... apparently AS27595 is back on the air, with aspath's like: > > 6461 23342 27595 > 6539 23342 27595 > 8075 23342 27595 > > 23342 == UnitedLayer, Tom isn't that you or is that another Tom I'm remembering? ah! someone reminded me that Tom left UL :( but at least I was remembering the right tom :) From tsparks at appliedops.net Mon Sep 22 16:25:54 2008 From: tsparks at appliedops.net (Tom Sparks (Applied Operations)) Date: Mon, 22 Sep 2008 14:25:54 -0700 Subject: Atrivo/Intercage In-Reply-To: <75cb24520809221417x2dc2b5afqf6345deef4b9ab72@mail.gmail.com> References: <20080922203331.GA57011@web1.wotanworks.net> <20080922205343.GJ35551@web1.wotanworks.net> <75cb24520809221417x2dc2b5afqf6345deef4b9ab72@mail.gmail.com> Message-ID: <20080922212554.GM35551@web1.wotanworks.net> On Mon, Sep 22, 2008 at 05:17:42PM -0400, Christopher Morrow wrote: > So... apparently AS27595 is back on the air, with aspath's like: > 6461 23342 27595 > 6539 23342 27595 > 8075 23342 27595 > > 23342 == UnitedLayer, Tom isn't that you or is that another > Tom I'm remembering? Yep, same Tom, I was one of the founders of UnitedLayer. I haven't been there since 2006, so its not my doing. I also noticed AS paths like this: * 69.22.162.0/23 701 2914 32335 6461 23342 27595 i I'm not sure whats going on there, but I'm thinking someone needs some help :) -- Tom Sparks (415) 367-7328x1001 From sharp at sharpone.net Mon Sep 22 16:35:54 2008 From: sharp at sharpone.net (Justin Sharp) Date: Mon, 22 Sep 2008 15:35:54 -0600 Subject: XO Outage Message-ID: <48D80FBA.50506@sharpone.net> We are seeing some issues w/ XO/Savvis peering.. Trace from XO to Savvis IP space (64.75.10.151) Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. scrubbed 0.0% 6 0.6 0.5 0.4 0.6 0.1 2. ip65-44-114-97.z114-44-65.customer.algx.net 0.0% 6 1.3 1.3 1.2 1.4 0.1 3. ??? Trace from Savvis to XO IP space (65.44.114.97) 1. scrubbed 0.0% 38 0.4 0.4 0.3 0.5 0.1 2. 64.41.199.129 0.0% 37 1.0 24.0 0.6 330.2 80.4 3. hr1-ge-7-47.santaclarasc5.savvis.net 0.0% 37 0.7 1.4 0.6 27.3 4.4 4. er1-te-1-0-0.sanjose3equinix.savvis.net 0.0% 37 0.7 5.2 0.6 140.3 23.2 5. cr1-tenge-0-7-5-0.sanfrancisco.savvis.net 2.7% 37 2.9 4.0 2.6 16.6 2.5 6. cr2-pos-0-0-3-3.dallas.savvis.net 0.0% 37 42.6 43.1 42.3 51.4 1.4 7. dpr1-ge-4-0-0.dallasequinix.savvis.net 0.0% 37 43.1 44.8 42.9 76.9 6.7 8. er1-te-2-1.dallasequinix.savvis.net 0.0% 37 43.3 49.2 42.8 233.6 31.6 9. 208.175.175.90 0.0% 37 43.0 42.8 42.6 43.6 0.2 10. 65.106.1.102 75.0% 37 43.5 46.5 43.4 62.9 6.3 11. 65.106.1.101 0.0% 37 43.4 47.8 43.2 112.3 12.5 12. 65.106.0.41 0.0% 37 57.5 65.1 57.1 177.3 21.0 13. 65.106.1.73 0.0% 37 57.4 66.5 57.1 162.1 24.2 14. ??? Trying to call into XO and they aren't even taking calls, they mention something about network issues in Spokane. Any ideas as to what is going on/ETA to fix? --Justin From asr+nanog at latency.net Mon Sep 22 16:38:46 2008 From: asr+nanog at latency.net (Adam Rothschild) Date: Mon, 22 Sep 2008 17:38:46 -0400 Subject: favourite XFP supplier? In-Reply-To: References: Message-ID: <20080922213846.GA24100@latency.net> On 2008-09-22-15:01:35, Joe Abley wrote: > Anybody have a preferred supplier for 10GE XFPs, multimode and > singlemode? Fluxlight (www.fluxlightinc.com) is good source for 10GBASE-SR and LR XFPs. They tend to keep an inventory, often able to ship on the day of order; their web store works; they run a reputable shop, and are fully understanding of "I'll need a tracking number ASAP, otherwise the facility you're sending them to might reject the shipment" -- all in all, a real win. If you have a Dell Premier account, you might want to check there, as they usually have XFPs listed at steep discount... If you're looking for exotics, such as ZR-D (DWDM), going with a Finisar reseller is a safe bet. I've had particularly good dealings with Cube Optics AG. (Fair warning: these are tougher to source on short notice.) HTH, -a From mike at digg.com Mon Sep 22 16:40:39 2008 From: mike at digg.com (mike newton) Date: Mon, 22 Sep 2008 14:40:39 -0700 Subject: XO Outage In-Reply-To: <48D80FBA.50506@sharpone.net> References: <48D80FBA.50506@sharpone.net> Message-ID: <48D810D7.9020107@digg.com> yeah, we noticed it as well. looks like they're back now. i noticed their routes drop off at about 14:16 PT and come back just after 14:30 PT. +m Justin Sharp wrote: > We are seeing some issues w/ XO/Savvis peering.. > > Trace from XO to Savvis IP space (64.75.10.151) > > Keys: Help Display mode Restart statistics Order of fields quit > > Packets Pings > Host > Loss% Snt Last Avg Best Wrst StDev > 1. scrubbed > > 0.0% 6 0.6 0.5 0.4 0.6 0.1 > 2. > ip65-44-114-97.z114-44-65.customer.algx.net > 0.0% 6 1.3 1.3 1.2 1.4 0.1 > 3. ??? > > > Trace from Savvis to XO IP space (65.44.114.97) > > 1. scrubbed > > 0.0% 38 0.4 0.4 0.3 0.5 0.1 > 2. > 64.41.199.129 > 0.0% 37 1.0 24.0 0.6 330.2 80.4 > 3. > hr1-ge-7-47.santaclarasc5.savvis.net > 0.0% 37 0.7 1.4 0.6 27.3 4.4 > 4. > er1-te-1-0-0.sanjose3equinix.savvis.net > 0.0% 37 0.7 5.2 0.6 140.3 23.2 > 5. > cr1-tenge-0-7-5-0.sanfrancisco.savvis.net > 2.7% 37 2.9 4.0 2.6 16.6 2.5 > 6. > cr2-pos-0-0-3-3.dallas.savvis.net > 0.0% 37 42.6 43.1 42.3 51.4 1.4 > 7. > dpr1-ge-4-0-0.dallasequinix.savvis.net > 0.0% 37 43.1 44.8 42.9 76.9 6.7 > 8. > er1-te-2-1.dallasequinix.savvis.net > 0.0% 37 43.3 49.2 42.8 233.6 31.6 > 9. > 208.175.175.90 > 0.0% 37 43.0 42.8 42.6 43.6 0.2 > 10. > 65.106.1.102 > 75.0% 37 43.5 46.5 43.4 62.9 6.3 > 11. > 65.106.1.101 > 0.0% 37 43.4 47.8 43.2 112.3 12.5 > 12. > 65.106.0.41 > 0.0% 37 57.5 65.1 57.1 177.3 21.0 > 13. > 65.106.1.73 > 0.0% 37 57.4 66.5 57.1 162.1 24.2 > 14. ??? > > Trying to call into XO and they aren't even taking calls, they mention > something about network issues in Spokane. Any ideas as to what is > going on/ETA to fix? > > --Justin > > From mike.lyon at gmail.com Mon Sep 22 16:43:49 2008 From: mike.lyon at gmail.com (Mike Lyon) Date: Mon, 22 Sep 2008 14:43:49 -0700 Subject: XO Outage In-Reply-To: <48D80FBA.50506@sharpone.net> References: <48D80FBA.50506@sharpone.net> Message-ID: <1b5c1c150809221443u312cec17j16db181d36484b28@mail.gmail.com> Also seeing some issues with XO out here: Tracing route to yahoo.com [68.180.206.184] over a maximum of 30 hops: 1 2 ms 1 ms 1 ms 10.100.20.1 2 2 ms 1 ms 2 ms sjcisr01-int.wyse.com [10.100.1.15] 3 3 ms 2 ms 2 ms 132.237.245.1 4 3 ms 3 ms 2 ms 207.88.3.37.ptr.us.xo.net [207.88.3.37] 5 7 ms 3 ms 3 ms p3-0-0.mar2.fremont-ca.us.xo.net [207.88.80.181] 6 16 ms 5 ms 3 ms p4-0-0.rar2.sanjose-ca.us.xo.net [65.106.5.137] 7 12 ms 14 ms 11 ms p6-0-0.rar1.la-ca.us.xo.net [65.106.0.17] 8 17 ms 11 ms 11 ms p0-0-0d0.rar2.la-ca.us.xo.net [65.106.1.50] 9 44 ms 50 ms 52 ms p6-0-0.rar1.dallas-tx.us.xo.net [65.106.0.13] 10 * * * Request timed out. 11 44 ms 44 ms 44 ms 207.88.12.150.ptr.us.xo.net [207.88.12.150] 12 53 ms 85 ms 52 ms 206.111.5.42.ptr.us.xo.net [206.111.5.42] ^C On Mon, Sep 22, 2008 at 2:35 PM, Justin Sharp wrote: > We are seeing some issues w/ XO/Savvis peering.. > > Trace from XO to Savvis IP space (64.75.10.151) > > Keys: Help Display mode Restart statistics Order of fields quit > > Packets Pings > Host > Loss% Snt Last Avg Best Wrst StDev > 1. scrubbed > 0.0% 6 0.6 0.5 0.4 0.6 0.1 > 2. ip65-44-114-97.z114-44-65.customer.algx.net > 0.0% 6 1.3 1.3 1.2 1.4 0.1 > 3. ??? > > > Trace from Savvis to XO IP space (65.44.114.97) > > 1. scrubbed > 0.0% 38 0.4 0.4 0.3 0.5 0.1 > 2. 64.41.199.129 > 0.0% 37 1.0 24.0 0.6 330.2 80.4 > 3. hr1-ge-7-47.santaclarasc5.savvis.net > 0.0% 37 0.7 1.4 0.6 27.3 4.4 > 4. er1-te-1-0-0.sanjose3equinix.savvis.net > 0.0% 37 0.7 5.2 0.6 140.3 23.2 > 5. cr1-tenge-0-7-5-0.sanfrancisco.savvis.net > 2.7% 37 2.9 4.0 2.6 16.6 2.5 > 6. cr2-pos-0-0-3-3.dallas.savvis.net > 0.0% 37 42.6 43.1 42.3 51.4 1.4 > 7. dpr1-ge-4-0-0.dallasequinix.savvis.net > 0.0% 37 43.1 44.8 42.9 76.9 6.7 > 8. er1-te-2-1.dallasequinix.savvis.net > 0.0% 37 43.3 49.2 42.8 233.6 31.6 > 9. 208.175.175.90 > 0.0% 37 43.0 42.8 42.6 43.6 0.2 > 10. 65.106.1.102 > 75.0% 37 43.5 46.5 43.4 62.9 6.3 > 11. 65.106.1.101 > 0.0% 37 43.4 47.8 43.2 112.3 12.5 > 12. 65.106.0.41 > 0.0% 37 57.5 65.1 57.1 177.3 21.0 > 13. 65.106.1.73 > 0.0% 37 57.4 66.5 57.1 162.1 24.2 > 14. ??? > > Trying to call into XO and they aren't even taking calls, they mention > something about network issues in Spokane. Any ideas as to what is going > on/ETA to fix? > > --Justin > > > From morrowc.lists at gmail.com Mon Sep 22 16:48:39 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 22 Sep 2008 17:48:39 -0400 Subject: Atrivo/Intercage In-Reply-To: <20080922212554.GM35551@web1.wotanworks.net> References: <20080922203331.GA57011@web1.wotanworks.net> <20080922205343.GJ35551@web1.wotanworks.net> <75cb24520809221417x2dc2b5afqf6345deef4b9ab72@mail.gmail.com> <20080922212554.GM35551@web1.wotanworks.net> Message-ID: <75cb24520809221448s4a1c8d45m342a0b280364ba52@mail.gmail.com> On Mon, Sep 22, 2008 at 5:25 PM, Tom Sparks (Applied Operations) wrote: > On Mon, Sep 22, 2008 at 05:17:42PM -0400, Christopher Morrow wrote: >> So... apparently AS27595 is back on the air, with aspath's like: >> 6461 23342 27595 >> 6539 23342 27595 >> 8075 23342 27595 >> >> 23342 == UnitedLayer, Tom isn't that you or is that another >> Tom I'm remembering? > > Yep, same Tom, I was one of the founders of UnitedLayer. > I haven't been there since 2006, so its not my doing. > yup, didn't particularly mean it was 'your doing' (even if you were there) but that perhaps (if you were still there) you might be able to influence the ops folks some... if you thought it worthy. > I also noticed AS paths like this: > * 69.22.162.0/23 701 2914 32335 6461 23342 27595 i > > I'm not sure whats going on there, but I'm thinking someone needs some help :) > yea I suspect that's a history route (or PIE re-opened the links between PIE/Atrivo). Or... Abovenet & PIE & NTT aren't filtering their customers in a way that keeps PIE form providing transit to NTT for Abovenet :( (NTT says loud and long they filter based on IRR data, PIE might not have updated their IRR info?) wierd though. From sharp at sharpone.net Mon Sep 22 16:48:56 2008 From: sharp at sharpone.net (Justin Sharp) Date: Mon, 22 Sep 2008 15:48:56 -0600 Subject: XO Outage In-Reply-To: <1b5c1c150809221443u312cec17j16db181d36484b28@mail.gmail.com> References: <48D80FBA.50506@sharpone.net> <1b5c1c150809221443u312cec17j16db181d36484b28@mail.gmail.com> Message-ID: <48D812C8.5060508@sharpone.net> Seems like Savvis/XO routes have been restored, albeit through an unusual Dallas route (usually takes an XO Los Angeles route).. 1. scrubbed 0.0% 204 0.4 0.7 0.3 7.0 0.9 2. ip65-44-114-97.z114-44-65.customer.algx.net 0.0% 204 1.8 1.8 1.1 8.4 1.2 3. ip65-46-48-29.z48-46-65.customer.algx.net 0.0% 204 3.3 6.3 2.8 96.4 9.0 4. p6-0-0-0.mar1.saltlake-ut.us.xo.net 0.5% 204 8.1 14.4 3.1 161.0 26.3 5. p4-1-0-0.rar1.denver-co.us.xo.net 0.0% 204 15.5 25.6 15.3 191.4 26.7 6. p0-0-0d0.rar2.denver-co.us.xo.net 0.0% 204 16.2 22.4 16.1 129.2 14.4 7. p1-0-0.rar2.dallas-tx.us.xo.net 0.0% 204 45.3 38.3 29.9 201.3 21.3 8. te-3-4-0.rar3.dallas-tx.us.xo.net 66.0% 204 30.3 34.2 29.6 116.2 11.6 9. 207.88.12.146.ptr.us.xo.net 0.0% 204 33.1 32.7 29.4 106.7 8.5 10. 208.175.175.89 0.0% 204 29.8 35.7 29.5 195.4 20.0 11. dpr1-ge-2-0-0.dallasequinix.savvis.net 0.0% 204 34.3 33.8 29.6 115.2 10.5 12. cr2-tengige0-7-5-0.dallas.savvis.net 1.5% 204 30.2 33.3 29.7 68.6 5.4 13. cr2-loopback.sfo.savvis.net 0.0% 203 75.1 209.8 74.0 3270. 493.7 14. er1-te-2-0-1.sanjose3equinix.savvis.net 0.0% 203 71.8 75.6 71.7 219.5 11.7 15. hr1-te-2-0-0.santaclarasc5.savvis.net 0.0% 203 72.1 75.5 72.0 194.0 9.4 16. 216.34.2.226 0.0% 203 72.3 105.4 72.1 723.7 102.5 17. 64.41.199.140 28.6% 203 77.5 74.9 72.0 183.1 9.7 18. scrubbed 0.0% 203 73.8 76.0 72.4 207.9 11.3 Hop 8 looks busy.. --Justin Mike Lyon wrote: > Also seeing some issues with XO out here: > > Tracing route to yahoo.com [68.180.206.184] > over a maximum of 30 hops: > > 1 2 ms 1 ms 1 ms 10.100.20.1 > 2 2 ms 1 ms 2 ms sjcisr01-int.wyse.com [10.100.1.15] > 3 3 ms 2 ms 2 ms 132.237.245.1 > 4 3 ms 3 ms 2 ms 207.88.3.37.ptr.us.xo.net [207.88.3.37] > 5 7 ms 3 ms 3 ms p3-0-0.mar2.fremont-ca.us.xo.net [207.88.80.181] > > 6 16 ms 5 ms 3 ms p4-0-0.rar2.sanjose-ca.us.xo.net [65.106.5.137] > > 7 12 ms 14 ms 11 ms p6-0-0.rar1.la-ca.us.xo.net [65.106.0.17] > 8 17 ms 11 ms 11 ms p0-0-0d0.rar2.la-ca.us.xo.net [65.106.1.50] > 9 44 ms 50 ms 52 ms p6-0-0.rar1.dallas-tx.us.xo.net [65.106.0.13] > 10 * * * Request timed out. > 11 44 ms 44 ms 44 ms 207.88.12.150.ptr.us.xo.net [207.88.12.150] > 12 53 ms 85 ms 52 ms 206.111.5.42.ptr.us.xo.net [206.111.5.42] > ^C > > > > On Mon, Sep 22, 2008 at 2:35 PM, Justin Sharp wrote: > >> We are seeing some issues w/ XO/Savvis peering.. >> >> Trace from XO to Savvis IP space (64.75.10.151) >> >> Keys: Help Display mode Restart statistics Order of fields quit >> >> Packets Pings >> Host >> Loss% Snt Last Avg Best Wrst StDev >> 1. scrubbed >> 0.0% 6 0.6 0.5 0.4 0.6 0.1 >> 2. ip65-44-114-97.z114-44-65.customer.algx.net >> 0.0% 6 1.3 1.3 1.2 1.4 0.1 >> 3. ??? >> >> >> Trace from Savvis to XO IP space (65.44.114.97) >> >> 1. scrubbed >> 0.0% 38 0.4 0.4 0.3 0.5 0.1 >> 2. 64.41.199.129 >> 0.0% 37 1.0 24.0 0.6 330.2 80.4 >> 3. hr1-ge-7-47.santaclarasc5.savvis.net >> 0.0% 37 0.7 1.4 0.6 27.3 4.4 >> 4. er1-te-1-0-0.sanjose3equinix.savvis.net >> 0.0% 37 0.7 5.2 0.6 140.3 23.2 >> 5. cr1-tenge-0-7-5-0.sanfrancisco.savvis.net >> 2.7% 37 2.9 4.0 2.6 16.6 2.5 >> 6. cr2-pos-0-0-3-3.dallas.savvis.net >> 0.0% 37 42.6 43.1 42.3 51.4 1.4 >> 7. dpr1-ge-4-0-0.dallasequinix.savvis.net >> 0.0% 37 43.1 44.8 42.9 76.9 6.7 >> 8. er1-te-2-1.dallasequinix.savvis.net >> 0.0% 37 43.3 49.2 42.8 233.6 31.6 >> 9. 208.175.175.90 >> 0.0% 37 43.0 42.8 42.6 43.6 0.2 >> 10. 65.106.1.102 >> 75.0% 37 43.5 46.5 43.4 62.9 6.3 >> 11. 65.106.1.101 >> 0.0% 37 43.4 47.8 43.2 112.3 12.5 >> 12. 65.106.0.41 >> 0.0% 37 57.5 65.1 57.1 177.3 21.0 >> 13. 65.106.1.73 >> 0.0% 37 57.4 66.5 57.1 162.1 24.2 >> 14. ??? >> >> Trying to call into XO and they aren't even taking calls, they mention >> something about network issues in Spokane. Any ideas as to what is going >> on/ETA to fix? >> >> --Justin >> >> >> >> From zaid at zaidali.com Mon Sep 22 16:49:46 2008 From: zaid at zaidali.com (Zaid Ali) Date: Mon, 22 Sep 2008 14:49:46 -0700 Subject: XO Outage In-Reply-To: <48D80FBA.50506@sharpone.net> References: <48D80FBA.50506@sharpone.net> Message-ID: <48D812FA.6050600@zaidali.com> I am seeing it on my end also: traceroute: Warning: www.cnn.com has multiple addresses; using 157.166.224.25 traceroute to www.cnn.com (157.166.224.25), 64 hops max, 40 byte packets 1 hq-rtr1.genius.local (64.244.66.1) 0.891 ms 0.429 ms 0.449 ms 2 ip65-46-253-157.z253-46-65.customer.algx.net (65.46.253.157) 1.856 ms 2.860 ms 1.881 ms 3 p3-0-0.mar2.fremont-ca.us.xo.net (207.88.80.181) 16.922 ms 2.041 ms 2.013 ms 4 p4-3-0.rar2.sanjose-ca.us.xo.net (65.106.5.161) 2.637 ms 2.192 ms 2.823 ms 5 p6-0-0.rar1.la-ca.us.xo.net (65.106.0.17) 10.308 ms 10.258 ms 10.386 ms 6 207.88.13.22.ptr.us.xo.net (207.88.13.22) 10.931 ms 10.535 ms 10.037 ms 7 *^C Justin Sharp wrote: > We are seeing some issues w/ XO/Savvis peering.. > > Trace from XO to Savvis IP space (64.75.10.151) > > Keys: Help Display mode Restart statistics Order of fields quit > > Packets Pings > Host > Loss% Snt Last Avg Best Wrst StDev > 1. scrubbed > > 0.0% 6 0.6 0.5 0.4 0.6 0.1 > 2. > ip65-44-114-97.z114-44-65.customer.algx.net > 0.0% 6 1.3 1.3 1.2 1.4 0.1 > 3. ??? > > > Trace from Savvis to XO IP space (65.44.114.97) > > 1. scrubbed > > 0.0% 38 0.4 0.4 0.3 0.5 0.1 > 2. > 64.41.199.129 > 0.0% 37 1.0 24.0 0.6 330.2 80.4 > 3. > hr1-ge-7-47.santaclarasc5.savvis.net > 0.0% 37 0.7 1.4 0.6 27.3 4.4 > 4. > er1-te-1-0-0.sanjose3equinix.savvis.net > 0.0% 37 0.7 5.2 0.6 140.3 23.2 > 5. > cr1-tenge-0-7-5-0.sanfrancisco.savvis.net > 2.7% 37 2.9 4.0 2.6 16.6 2.5 > 6. > cr2-pos-0-0-3-3.dallas.savvis.net > 0.0% 37 42.6 43.1 42.3 51.4 1.4 > 7. > dpr1-ge-4-0-0.dallasequinix.savvis.net > 0.0% 37 43.1 44.8 42.9 76.9 6.7 > 8. > er1-te-2-1.dallasequinix.savvis.net > 0.0% 37 43.3 49.2 42.8 233.6 31.6 > 9. > 208.175.175.90 > 0.0% 37 43.0 42.8 42.6 43.6 0.2 > 10. > 65.106.1.102 > 75.0% 37 43.5 46.5 43.4 62.9 6.3 > 11. > 65.106.1.101 > 0.0% 37 43.4 47.8 43.2 112.3 12.5 > 12. > 65.106.0.41 > 0.0% 37 57.5 65.1 57.1 177.3 21.0 > 13. > 65.106.1.73 > 0.0% 37 57.4 66.5 57.1 162.1 24.2 > 14. ??? > > Trying to call into XO and they aren't even taking calls, they mention > something about network issues in Spokane. Any ideas as to what is going > on/ETA to fix? > > --Justin > > From morrowc.lists at gmail.com Mon Sep 22 16:50:58 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 22 Sep 2008 17:50:58 -0400 Subject: Atrivo/Intercage In-Reply-To: <75cb24520809221448s4a1c8d45m342a0b280364ba52@mail.gmail.com> References: <20080922203331.GA57011@web1.wotanworks.net> <20080922205343.GJ35551@web1.wotanworks.net> <75cb24520809221417x2dc2b5afqf6345deef4b9ab72@mail.gmail.com> <20080922212554.GM35551@web1.wotanworks.net> <75cb24520809221448s4a1c8d45m342a0b280364ba52@mail.gmail.com> Message-ID: <75cb24520809221450h15ab4bc6u4eca465602c73f45@mail.gmail.com> On Mon, Sep 22, 2008 at 5:48 PM, Christopher Morrow wrote: > On Mon, Sep 22, 2008 at 5:25 PM, Tom Sparks (Applied Operations) > wrote: >> I also noticed AS paths like this: >> * 69.22.162.0/23 701 2914 32335 6461 23342 27595 i >> >> I'm not sure whats going on there, but I'm thinking someone needs some help :) >> > > yea I suspect that's a history route (or PIE re-opened the links > between PIE/Atrivo). Or... Abovenet & PIE & NTT aren't filtering their > customers in a way that keeps PIE form providing transit to NTT for > Abovenet :( (NTT says loud and long they filter based on IRR data, PIE > might not have updated their IRR info?) > > wierd though. > actually, I think PIE sees this route from 6461 and passes it along probably because they didn't update the filters on their sessions when they dropped the links to 27595 :( Also they didn't update the IRR data to remove this set of prefixes. bummers. From tsparks at appliedops.net Mon Sep 22 17:00:15 2008 From: tsparks at appliedops.net (Tom Sparks (Applied Operations)) Date: Mon, 22 Sep 2008 15:00:15 -0700 Subject: Atrivo/Intercage In-Reply-To: <75cb24520809221450h15ab4bc6u4eca465602c73f45@mail.gmail.com> References: <20080922203331.GA57011@web1.wotanworks.net> <20080922205343.GJ35551@web1.wotanworks.net> <75cb24520809221417x2dc2b5afqf6345deef4b9ab72@mail.gmail.com> <20080922212554.GM35551@web1.wotanworks.net> <75cb24520809221448s4a1c8d45m342a0b280364ba52@mail.gmail.com> <75cb24520809221450h15ab4bc6u4eca465602c73f45@mail.gmail.com> Message-ID: <20080922220015.GS35551@web1.wotanworks.net> On Mon, Sep 22, 2008 at 05:50:58PM -0400, Christopher Morrow wrote: > actually, I think PIE sees this route from 6461 and passes it along > probably because they didn't update the filters on their sessions when > they dropped the links to 27595 :( Has anyone actually confirmed that the link is dropped with PIE? > Also they didn't update the IRR data to remove this set of prefixes. Looks like they've got all kindsa stuff in there... -- Tom Sparks (415) 367-7328x1001 From justin at justinshore.com Mon Sep 22 17:00:35 2008 From: justin at justinshore.com (Justin Shore) Date: Mon, 22 Sep 2008 17:00:35 -0500 Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: <5D20455D-01B1-4406-AAEE-FFD9654DDF59@ianai.net> References: <20080908112049.256D9BBE@resin13.mta.everyone.net> <200809110850.25652.lowen@pari.edu> <5D20455D-01B1-4406-AAEE-FFD9654DDF59@ianai.net> Message-ID: <48D81582.2030904@justinshore.com> Patrick W. Gilmore wrote: > There is no law or even custom stopping me from asking you to prove you > are worthy to connect to my network. There may not be a law preventing you from asking him for proof of legitimate customers, but there is a law preventing him from answering you. Google for CPNI and "red flag". Justin From mark.foo.dog at gmail.com Mon Sep 22 18:27:53 2008 From: mark.foo.dog at gmail.com (Mark Foo) Date: Mon, 22 Sep 2008 16:27:53 -0700 Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer Message-ID: <1bbf3c240809221627wa9e6879h82a81aa8b433ec92@mail.gmail.com> On Sun, Sep 21, 2008 at 12:46:54PM -0700, Emil Kacperski wrote: > Hey James, > > That's the worst part in all this, so many been with me for years!? I just put my fate into companies I shouldn't have. Emil: Yes, they have been with you for years -- it's quite unfortunate, such great customers. Take those customers who steal identity from the public -- did you get a cut, or just the hosting fees? Next, move to those who host trojans, rogue antivirus, bill people for fake software (and keep billing them), etc. Oh, and the ad-ware, despite being a lower security risk, it was some of the most hated stuff out there. I'd say you have put your fate into companies you shouldn't have -- not just your fate but your business. This is the logical result (actually, this is just the start). I'm surprised it took so long. You can't wash away years of malicious activity by simply claiming innocence and disconnecting some of your worst offenders. Male parta male dilabuntur. For the NANOG folks who apparently don't understand what is going on and are so easily socially engineered by these claims of innocence -- do a little research: http://www.google.com/search?hl=en&q=intercage+malware http://www.google.com/search?hl=en&q=atrivo+malware ======================================================== Here's some research for you: Complaints on Intercage/Atrivo from 2003: Re: The in-your-face hijacking example http://www.irbs.net/internet/nanog/0305/0038.html ======================================================== >From 2006: More super rogue anti-spyware http://updates.zdnet.com/tags/intercage.com.html Be on the lookout for another new supposed anti-spyware program that might be hijacking desktops any day now. This one is called PestTrap and it.s a clone of SpySheriff. SpySheriff was one of the top 10 rogue anti-spyware apps of 2005, coming in at number 2. PestTrap site is hosted at IP address 69.50.167.173 which belongs to an ISP in California, InterCage, Inc., formerly know n as Atrivo. Note the nameservers are mail.atrrivo.com and pavel.atrivo.com . OrgName: InterCage, Inc. OrgID: INTER-359 Address: 1955 Monument Blvd. Address: #236 City: Concord StateProv: CA PostalCode: 94520 Country: US Not surprisingly, SpySheriff.com (link to whois) is hosted at InterCage, and we have SpyTrooper.com on the same IP address, 69.50.170.82. The other domain on the IP is Spy-Sheriff.com. This IP is also currently blacklisted. InterCage, Inc. INTERCAGE-NETWORK-GROUP (NET-69-50-160-0-1) 69.50.160.0 - 69.50.191.255 William Lu STANDARDSHELLS (NET-69-50-170-0-1) 69.50.170.0 - 69.50.170.255 The Intercage.com (link to site) home page is white and blank except for "." in the upper left corner. Now, that seems odd to me. An ISP with a blank homepage? Google searches for Intercage.com and Intercage, Inc. bring up all kinds of interesting links. A Google search for Atrivo produces even more fascinating information like this and this. More on this one later. From marka at isc.org Mon Sep 22 18:32:23 2008 From: marka at isc.org (Mark Andrews) Date: Tue, 23 Sep 2008 09:32:23 +1000 (EST) Subject: hat tip to .gov hostmasters In-Reply-To: <82ljxkjjan.fsf@mid.bfk.de> References: <6BCAB7B989C2EA4AAD36652C14D4FB4563512B@FHDP1CCMXCV02.us.one.verizon.com> Message-ID: <200809222332.m8MNWNUv068580@drugs.dv.isc.org> In article <82ljxkjjan.fsf at mid.bfk.de> you write: >* marcus sachs: > >> While we wait for applications to become DNSSEC-aware, > >Uhm, applications shouldn't be DNSSEC-aware. Down that road lies >madness. What should an end user do when the browser tells him, >"Warning: Could not validate DNSSEC signature on www.example.com, >signature has expired. Continue to connect?" The application just rejects the answer. Trys again a couple of times then reports failure. This is no different to the application talking to the validating resolver a couple of time and then reporting failure. The advantage of having the application do it is that you don't need to secure the connection between the validating resolver and the application. Mark From patrick at ianai.net Mon Sep 22 18:46:23 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 22 Sep 2008 19:46:23 -0400 Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: <48D81582.2030904@justinshore.com> References: <20080908112049.256D9BBE@resin13.mta.everyone.net> <200809110850.25652.lowen@pari.edu> <5D20455D-01B1-4406-AAEE-FFD9654DDF59@ianai.net> <48D81582.2030904@justinshore.com> Message-ID: <2293FAFB-1E2B-4994-B22C-93E1235A57EA@ianai.net> That does not stop me from asking. Also, I've never seen a viable, legit biz that didn't have at least a couple customers who were willing to let their name be used. -- TTFN, patrick iPhone 3-J (That's 3-Jezuz for the uninitiated.) On Sep 22, 2008, at 18:00, Justin Shore wrote: > Patrick W. Gilmore wrote: >> There is no law or even custom stopping me from asking you to prove >> you are worthy to connect to my network. > > There may not be a law preventing you from asking him for proof of > legitimate customers, but there is a law preventing him from > answering you. Google for CPNI and "red flag". > > Justin > From surfer at mauigateway.com Mon Sep 22 20:06:58 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 22 Sep 2008 18:06:58 -0700 Subject: prefix hijack by ASN 8997 Message-ID: <20080922180658.7901E5DA@resin11.mta.everyone.net> I am hoping to confirm a short-duration prefix hijack of 72.234.0.0/15 (and another of our prefixes) by ASN 8997 ("OJSC North-West Telecom" in Russia) in using ASN 3267 (Russian Federal University Network) to advertise our space to ASN 3277 (Regional University and Scientific Network (RUSNet) of North-Western and Saint-Petersburg Area of Russia). Is that what I'm seeing when I go to "bgplay.routeviews.org/bgplay", put in prefix 72.234.0.0/15 and select the dates: 22/9/2008 9:00:00 and 22/9/2008 15:00:00 If so, am I understanding it correctly if I say ASN 3267 saw a shorter path from ASN 8997, so refused the proper announcement from ASN 36149 (me) it normally hears from ASN 174 (Cogent). If the above two are correct, would it be correct to say only the downstream customers of ASN 3267 were affected? scott From Valdis.Kletnieks at vt.edu Mon Sep 22 20:07:09 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 22 Sep 2008 21:07:09 -0400 Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: Your message of "Mon, 22 Sep 2008 17:00:35 CDT." <48D81582.2030904@justinshore.com> References: <20080908112049.256D9BBE@resin13.mta.everyone.net> <200809110850.25652.lowen@pari.edu> <5D20455D-01B1-4406-AAEE-FFD9654DDF59@ianai.net> <48D81582.2030904@justinshore.com> Message-ID: <66536.1222132029@turing-police.cc.vt.edu> On Mon, 22 Sep 2008 17:00:35 CDT, Justin Shore said: > There may not be a law preventing you from asking him for proof of > legitimate customers, but there is a law preventing him from answering > you. Google for CPNI and "red flag". Hmm... I'm not sure how "Yes, XYZ is a customer of mine" qualifies as a "red flag" question for identity theft. I'm also not sure how "XYZ is a customer" qualifies as CPNI, which (according to the first few pages of Google hits) comprises things like calling/billing records. http://www.privacyalerts.org/phone-records.html says: For clarity, a "record" in this section is the same thing as a "call log" or a "text log." A "phone record" typically includes: date, time, sender geographic location, recipient phone number, recipient geographic location, and duration of call. A "text record" includes: date, time, and recipient phone number. Nope. Doesn't seem like "xyz is a customer" qualifies there... http://www.ipbusinessmag.com/articles.php?issue_id=63&article_id=387 says: Space does not permit an extended review of the FTC rules here, but they apply to "creditors" who maintain ongoing accounts with customers for repeated transactions. Cell phone accounts are offered by the rules as one example of a "covered" account which is subject to the rules. If a business maintains such "covered accounts" it must comply with the new rules to prevent identity theft of its account holders. Hmm... "xyz is a customer" doesn't seem to run afoul of that either. Feel free to enlighten me about what I missed here? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From christian at broknrobot.com Mon Sep 22 20:20:36 2008 From: christian at broknrobot.com (Christian Koch) Date: Mon, 22 Sep 2008 21:20:36 -0400 Subject: prefix hijack by ASN 8997 In-Reply-To: <20080922180658.7901E5DA@resin11.mta.everyone.net> References: <20080922180658.7901E5DA@resin11.mta.everyone.net> Message-ID: I received a phas notification about this today as well... I couldn't find any relevant data confirming the announcement of one of my /19 blocks, until a few minutes ago when i checked the route views bgplay (ripe bgplay turns up nothing) and can now see 8997 announcing and quickly withdrawing my prefix On Mon, Sep 22, 2008 at 9:06 PM, Scott Weeks wrote: > > > > I am hoping to confirm a short-duration prefix hijack of 72.234.0.0/15 (and another of our prefixes) by ASN 8997 ("OJSC North-West Telecom" in Russia) in using ASN 3267 (Russian Federal University Network) to advertise our space to ASN 3277 (Regional University and Scientific Network (RUSNet) of North-Western and Saint-Petersburg Area of Russia). > > Is that what I'm seeing when I go to "bgplay.routeviews.org/bgplay", put in prefix 72.234.0.0/15 and select the dates: > > 22/9/2008 9:00:00 and 22/9/2008 15:00:00 > > If so, am I understanding it correctly if I say ASN 3267 saw a shorter path from ASN 8997, so refused the proper announcement from ASN 36149 (me) it normally hears from ASN 174 (Cogent). > > If the above two are correct, would it be correct to say only the downstream customers of ASN 3267 were affected? > > scott > > From surfer at mauigateway.com Mon Sep 22 20:31:56 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 22 Sep 2008 18:31:56 -0700 Subject: prefix hijack by ASN 8997 Message-ID: <20080922183156.7901E233@resin11.mta.everyone.net> ----------Scott Weeks wrote: ------- > I am hoping to confirm a short-duration prefix hijack ------------------------------------- --- christian at broknrobot.com wrote: ------- From: "Christian Koch" I couldn't find any relevant data confirming the announcement of one of my /19 blocks, until a few minutes ago when i checked the route views bgplay (ripe bgplay turns up nothing) and can now see 8997 announcing and quickly withdrawing my prefix ------------------------------------- At what time did you see it? scott From christian at broknrobot.com Mon Sep 22 20:39:37 2008 From: christian at broknrobot.com (Christian Koch) Date: Mon, 22 Sep 2008 21:39:37 -0400 Subject: prefix hijack by ASN 8997 In-Reply-To: <20080922183156.7901E233@resin11.mta.everyone.net> References: <20080922183156.7901E233@resin11.mta.everyone.net> Message-ID: about 09:30 UTC per rviews On Mon, Sep 22, 2008 at 9:31 PM, Scott Weeks wrote: > > ----------Scott Weeks wrote: ------- > >> I am hoping to confirm a short-duration prefix hijack > > ------------------------------------- > > --- christian at broknrobot.com wrote: ------- > From: "Christian Koch" > > I couldn't find any relevant data confirming the announcement of one > of my /19 blocks, until a few minutes ago when i checked the route > views bgplay (ripe bgplay turns up nothing) and can now see 8997 > announcing and quickly withdrawing my prefix > ------------------------------------- > > > At what time did you see it? > > scott > > From yahoo at jimpop.com Mon Sep 22 21:13:02 2008 From: yahoo at jimpop.com (Jim Popovitch) Date: Mon, 22 Sep 2008 22:13:02 -0400 Subject: prefix hijack by ASN 8997 In-Reply-To: <20080922180658.7901E5DA@resin11.mta.everyone.net> References: <20080922180658.7901E5DA@resin11.mta.everyone.net> Message-ID: <7ff145960809221913o1298820asf883adad7ce85628@mail.gmail.com> On Mon, Sep 22, 2008 at 21:06, Scott Weeks wrote: > > I am hoping to confirm a short-duration prefix hijack of 72.234.0.0/15 (and another of our > prefixes) by ASN 8997 ("OJSC North-West Telecom" in Russia) in using ASN 3267 > (Russian Federal University Network) to advertise our space to ASN 3277 (Regional > University and Scientific Network (RUSNet) of North-Western and Saint-Petersburg > Area of Russia). Yep, saw this for 69.61.0.0/17 GlobalCompass (my upstream) this AM: SEQUENCE_NUMBER: 1222091638 TYPE: last-hop BGP-UPDATE-TIME: 1222075864 PHAS-DETECT-TIME: 1222091637 PHAS-NOTIFY-TIME: 1222091637 PREFIX: 69.61.0.0/17 SET: 3561,3267,3356,3491 GAINED: 3267 <- Russian Federal University Network LOST: SEQUENCE_NUMBER: 1222091638 TYPE: origin BGP-UPDATE-TIME: 1222075864 PHAS-DETECT-TIME: 1222091637 PHAS-NOTIFY-TIME: 1222091637 PREFIX: 69.61.0.0/17 SET: 8997,22653 GAINED: 8997 <- OJSC North-West Telecom, St.-Petersburg, Russia LOST: SEQUENCE_NUMBER: 1222096125 TYPE: origin BGP-UPDATE-TIME: 1222076569 PHAS-DETECT-TIME: 1222092415 PHAS-NOTIFY-TIME: 1222096124 PREFIX: 69.61.0.0/17 SET: 22653 <- GlobalCrossing GAINED: LOST: 8997 -Jim P. From jensenja at gmail.com Mon Sep 22 21:54:17 2008 From: jensenja at gmail.com (John Jensen) Date: Mon, 22 Sep 2008 19:54:17 -0700 Subject: duplicate packet In-Reply-To: <20080910121148.GA4491@sephina.sabt.net> References: <473679.44924.qm@web57413.mail.re1.yahoo.com> <20080910121148.GA4491@sephina.sabt.net> Message-ID: <6de481d10809221954p7b45cbdby641f9603a4a40a3f@mail.gmail.com> She'd have to actually specify -b to ping a broadcast address, and if she did, she would only get replies back from the hosts on that subnet, not duplicate replies from the same IP. On Wed, Sep 10, 2008 at 5:11 AM, Sebastian Abt wrote: > * chloe K wrote: >> When I ping the ip, I get the duplicate >> >> 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.344 ms >> 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.401 ms (DUP!) > ^^^^^^^^^^^^ > What's your netmask? Is 192.168.0.95 your net's broadcast address? > > sebastian > > -- > SABT-RIPE PGPKEY-D008DA9C > > From jensenja at gmail.com Mon Sep 22 21:55:41 2008 From: jensenja at gmail.com (John Jensen) Date: Mon, 22 Sep 2008 19:55:41 -0700 Subject: duplicate packet In-Reply-To: <6de481d10809221954p7b45cbdby641f9603a4a40a3f@mail.gmail.com> References: <473679.44924.qm@web57413.mail.re1.yahoo.com> <20080910121148.GA4491@sephina.sabt.net> <6de481d10809221954p7b45cbdby641f9603a4a40a3f@mail.gmail.com> Message-ID: <6de481d10809221955s2af9cd5crf887881c5d9a6116@mail.gmail.com> At least I think that's how it works. :) On Mon, Sep 22, 2008 at 7:54 PM, John Jensen wrote: > She'd have to actually specify -b to ping a broadcast address, and if > she did, she would only get replies back from the hosts on that > subnet, not duplicate replies from the same IP. > > On Wed, Sep 10, 2008 at 5:11 AM, Sebastian Abt wrote: >> * chloe K wrote: >>> When I ping the ip, I get the duplicate >>> >>> 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.344 ms >>> 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.401 ms (DUP!) >> ^^^^^^^^^^^^ >> What's your netmask? Is 192.168.0.95 your net's broadcast address? >> >> sebastian >> >> -- >> SABT-RIPE PGPKEY-D008DA9C >> >> > From Valdis.Kletnieks at vt.edu Mon Sep 22 22:30:27 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 22 Sep 2008 23:30:27 -0400 Subject: duplicate packet In-Reply-To: Your message of "Mon, 22 Sep 2008 19:54:17 PDT." <6de481d10809221954p7b45cbdby641f9603a4a40a3f@mail.gmail.com> References: <473679.44924.qm@web57413.mail.re1.yahoo.com> <20080910121148.GA4491@sephina.sabt.net> <6de481d10809221954p7b45cbdby641f9603a4a40a3f@mail.gmail.com> Message-ID: <72850.1222140627@turing-police.cc.vt.edu> On Mon, 22 Sep 2008 19:54:17 PDT, John Jensen said: > She'd have to actually specify -b to ping a broadcast address, Only true if you're pinging the broadcast address of a network that you have an interface on, or the system has other knowledge of the netmask/etc. If you're pinging a remote address, your system (in general) has no way of knowing if that .0.95 is a broadcast address for a /27, or a normal address in the middle of a /26 (or one of the other possibilities). (I've lost the original posting, and can't recall if the OP said if she was pinging from on-subnet or off-subnet). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From justin at justinshore.com Mon Sep 22 23:27:01 2008 From: justin at justinshore.com (Justin Shore) Date: Mon, 22 Sep 2008 23:27:01 -0500 Subject: prefix hijack by ASN 8997 In-Reply-To: References: <20080922180658.7901E5DA@resin11.mta.everyone.net> Message-ID: <48D87015.4030802@justinshore.com> Looking up some of my prefixes in PHAS and BGPPlay, I too see my prefixes being advertised by 8997 for a short time. It looks like it happened around 1222091563 according to PHAS. Was this a mistake or something else? Justin Christian Koch wrote: > I received a phas notification about this today as well... > > I couldn't find any relevant data confirming the announcement of one > of my /19 blocks, until a few minutes ago when i checked the route > views bgplay (ripe bgplay turns up nothing) and can now see 8997 > announcing and quickly withdrawing my prefix > > > > > On Mon, Sep 22, 2008 at 9:06 PM, Scott Weeks wrote: >> >> >> I am hoping to confirm a short-duration prefix hijack of 72.234.0.0/15 (and another of our prefixes) by ASN 8997 ("OJSC North-West Telecom" in Russia) in using ASN 3267 (Russian Federal University Network) to advertise our space to ASN 3277 (Regional University and Scientific Network (RUSNet) of North-Western and Saint-Petersburg Area of Russia). >> >> Is that what I'm seeing when I go to "bgplay.routeviews.org/bgplay", put in prefix 72.234.0.0/15 and select the dates: >> >> 22/9/2008 9:00:00 and 22/9/2008 15:00:00 >> >> If so, am I understanding it correctly if I say ASN 3267 saw a shorter path from ASN 8997, so refused the proper announcement from ASN 36149 (me) it normally hears from ASN 174 (Cogent). >> >> If the above two are correct, would it be correct to say only the downstream customers of ASN 3267 were affected? >> >> scott >> >> > From hank at efes.iucc.ac.il Mon Sep 22 23:32:34 2008 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 23 Sep 2008 07:32:34 +0300 (IDT) Subject: prefix hijack by ASN 8997 In-Reply-To: <20080922180658.7901E5DA@resin11.mta.everyone.net> References: <20080922180658.7901E5DA@resin11.mta.everyone.net> Message-ID: On Mon, 22 Sep 2008, Scott Weeks wrote: I too spotted this via PHAS for a large number of prefixes, but have not received alerts from IAR, Watchmy.Net nor does RIPE RIS show this hijack: http://www.ris.ripe.net/perl-risapp/risearch.html I would have expected with so many RRC boxes that RIPE RIS would have caught it. I had thought it was a false positive from PHAS but now that you and others have seen it - I guess it is for real. -Hank > > > > I am hoping to confirm a short-duration prefix hijack of 72.234.0.0/15 (and another of our prefixes) by ASN 8997 ("OJSC North-West Telecom" in Russia) in using ASN 3267 (Russian Federal University Network) to advertise our space to ASN 3277 (Regional University and Scientific Network (RUSNet) of North-Western and Saint-Petersburg Area of Russia). > > Is that what I'm seeing when I go to "bgplay.routeviews.org/bgplay", put in prefix 72.234.0.0/15 and select the dates: > > 22/9/2008 9:00:00 and 22/9/2008 15:00:00 > > If so, am I understanding it correctly if I say ASN 3267 saw a shorter path from ASN 8997, so refused the proper announcement from ASN 36149 (me) it normally hears from ASN 174 (Cogent). > > If the above two are correct, would it be correct to say only the downstream customers of ASN 3267 were affected? > > scott > From hank at efes.iucc.ac.il Mon Sep 22 23:34:40 2008 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 23 Sep 2008 07:34:40 +0300 (IDT) Subject: prefix hijack by ASN 8997 In-Reply-To: References: <20080922180658.7901E5DA@resin11.mta.everyone.net> Message-ID: On Mon, 22 Sep 2008, Christian Koch wrote: Strange that RIPE RIS search doesn't show it: http://www.ris.ripe.net/perl-risapp/risearch.html but yet you say BGPlay does show it. -Hank > I received a phas notification about this today as well... > > I couldn't find any relevant data confirming the announcement of one > of my /19 blocks, until a few minutes ago when i checked the route > views bgplay (ripe bgplay turns up nothing) and can now see 8997 > announcing and quickly withdrawing my prefix > > > > > On Mon, Sep 22, 2008 at 9:06 PM, Scott Weeks wrote: >> >> >> >> I am hoping to confirm a short-duration prefix hijack of 72.234.0.0/15 (and another of our prefixes) by ASN 8997 ("OJSC North-West Telecom" in Russia) in using ASN 3267 (Russian Federal University Network) to advertise our space to ASN 3277 (Regional University and Scientific Network (RUSNet) of North-Western and Saint-Petersburg Area of Russia). >> >> Is that what I'm seeing when I go to "bgplay.routeviews.org/bgplay", put in prefix 72.234.0.0/15 and select the dates: >> >> 22/9/2008 9:00:00 and 22/9/2008 15:00:00 >> >> If so, am I understanding it correctly if I say ASN 3267 saw a shorter path from ASN 8997, so refused the proper announcement from ASN 36149 (me) it normally hears from ASN 174 (Cogent). >> >> If the above two are correct, would it be correct to say only the downstream customers of ASN 3267 were affected? >> >> scott >> >> > From christian at broknrobot.com Mon Sep 22 23:58:07 2008 From: christian at broknrobot.com (Christian Koch) Date: Tue, 23 Sep 2008 00:58:07 -0400 Subject: prefix hijack by ASN 8997 In-Reply-To: <48D87015.4030802@justinshore.com> References: <20080922180658.7901E5DA@resin11.mta.everyone.net> <48D87015.4030802@justinshore.com> Message-ID: At first glance this morning not seeing any data between the gain and lost alerts from phas and inability to find a route in any of the many collectors and route servers out there I had thought it was a possibly a fat finger mistake by 8997 or a false positive. After locating the data in bgplay/rviews, and noticing how many more people this occured to I'm leaning towards 2 possible scenarios: 1 - bgp misconfigurations leading to leaks (Depends on the overall scale of how many other prefixes were possibly announced) 2 - 8997 began announcing prefixes as an experiment to "test the waters" for potential real hijacks in future... 'geography' hints towards #2 Or both theories could be way off :) I'd be interested to know if Renesys collected any data that might give some better insight to this... Christian On 9/23/08, Justin Shore wrote: > Looking up some of my prefixes in PHAS and BGPPlay, I too see my > prefixes being advertised by 8997 for a short time. It looks like it > happened around 1222091563 according to PHAS. > > Was this a mistake or something else? > > Justin > > > Christian Koch wrote: >> I received a phas notification about this today as well... >> >> I couldn't find any relevant data confirming the announcement of one >> of my /19 blocks, until a few minutes ago when i checked the route >> views bgplay (ripe bgplay turns up nothing) and can now see 8997 >> announcing and quickly withdrawing my prefix >> >> >> >> >> On Mon, Sep 22, 2008 at 9:06 PM, Scott Weeks >> wrote: >>> >>> >>> I am hoping to confirm a short-duration prefix hijack of 72.234.0.0/15 >>> (and another of our prefixes) by ASN 8997 ("OJSC North-West Telecom" in >>> Russia) in using ASN 3267 (Russian Federal University Network) to >>> advertise our space to ASN 3277 (Regional University and Scientific >>> Network (RUSNet) of North-Western and Saint-Petersburg Area of Russia). >>> >>> Is that what I'm seeing when I go to "bgplay.routeviews.org/bgplay", put >>> in prefix 72.234.0.0/15 and select the dates: >>> >>> 22/9/2008 9:00:00 and 22/9/2008 15:00:00 >>> >>> If so, am I understanding it correctly if I say ASN 3267 saw a shorter >>> path from ASN 8997, so refused the proper announcement from ASN 36149 >>> (me) it normally hears from ASN 174 (Cogent). >>> >>> If the above two are correct, would it be correct to say only the >>> downstream customers of ASN 3267 were affected? >>> >>> scott >>> >>> >> > -- Sent from my mobile device From christian at broknrobot.com Tue Sep 23 00:00:27 2008 From: christian at broknrobot.com (Christian Koch) Date: Tue, 23 Sep 2008 01:00:27 -0400 Subject: prefix hijack by ASN 8997 In-Reply-To: References: <20080922180658.7901E5DA@resin11.mta.everyone.net> Message-ID: Bgplay on routeviews, not the ripe one :) Christian On 9/23/08, Hank Nussbacher wrote: > On Mon, 22 Sep 2008, Christian Koch wrote: > > Strange that RIPE RIS search doesn't show it: > http://www.ris.ripe.net/perl-risapp/risearch.html > but yet you say BGPlay does show it. > > -Hank > >> I received a phas notification about this today as well... >> >> I couldn't find any relevant data confirming the announcement of one >> of my /19 blocks, until a few minutes ago when i checked the route >> views bgplay (ripe bgplay turns up nothing) and can now see 8997 >> announcing and quickly withdrawing my prefix >> >> >> >> >> On Mon, Sep 22, 2008 at 9:06 PM, Scott Weeks >> wrote: >>> >>> >>> >>> I am hoping to confirm a short-duration prefix hijack of 72.234.0.0/15 >>> (and another of our prefixes) by ASN 8997 ("OJSC North-West Telecom" in >>> Russia) in using ASN 3267 (Russian Federal University Network) to >>> advertise our space to ASN 3277 (Regional University and Scientific >>> Network (RUSNet) of North-Western and Saint-Petersburg Area of Russia). >>> >>> Is that what I'm seeing when I go to "bgplay.routeviews.org/bgplay", put >>> in prefix 72.234.0.0/15 and select the dates: >>> >>> 22/9/2008 9:00:00 and 22/9/2008 15:00:00 >>> >>> If so, am I understanding it correctly if I say ASN 3267 saw a shorter >>> path from ASN 8997, so refused the proper announcement from ASN 36149 >>> (me) it normally hears from ASN 174 (Cogent). >>> >>> If the above two are correct, would it be correct to say only the >>> downstream customers of ASN 3267 were affected? >>> >>> scott >>> >>> >> > -- Sent from my mobile device From andree+nanog at toonk.nl Tue Sep 23 01:33:53 2008 From: andree+nanog at toonk.nl (Andree Toonk) Date: Tue, 23 Sep 2008 08:33:53 +0200 Subject: prefix hijack by ASN 8997 In-Reply-To: References: <20080922180658.7901E5DA@resin11.mta.everyone.net> Message-ID: <20080923063353.GA3558@toonk.nl> Hi, .-- My secret spy satellite informs me that at Tue, 23 Sep 2008, Hank Nussbacher wrote: > I too spotted this via PHAS for a large number of prefixes, but have not > received alerts from IAR, Watchmy.Net nor does RIPE RIS show this hijack: > http://www.ris.ripe.net/perl-risapp/risearch.html I would have expected > with so many RRC boxes that RIPE RIS would have caught it. I had thought > it was a false positive from PHAS but now that you and others have seen > it - I guess it is for real. Not a false positive, It actually was detected by the RIS box in Moscow (rrc13). Strange that it's not visible in RIS search website, but it's definitely in the raw data files. Looking at that raw data from both routeviews and Ripe, it looks like they (AS8997) 'leaked' a full table, i.e. : * 217.208 unique prefixes detected by the RIS server in Moscow (ASpath: 2895 3267 8997) * 250495 seen by routeviews (ASpath: 2895 3267 8997). (results of quick query: where AS-path contained '3267 8997' update type = advertisement). I'm using another prefix monitoring tool and within a few minutes it notified me of this hijack for some of our prefixes: <> ==================== Prefix Hijack ( Code 11: Origin AS and Prefix changed (more specific) Or Origin AS changed) detected 1 updates for your prefix 128.189.0.0/16 AS271: Update details: 2008-09-22 09:33 (UTC) 128.189.0.0/16 Announced by: AS8997 (ASN-SPBNIT OJSC North-West Telecom Autonomous System), Transit AS: AS3267 (RUNNET RUNNet) ASpath: 2895 3267 8997 ==================== Prefix Hijack ( Code 11: Origin AS and Prefix changed (more specific) Or Origin AS changed) detected 1 updates for your prefix 142.231.0.0/16 AS271: Update details: 2008-09-22 09:34 (UTC) 142.231.0.0/16 Announced by: AS8997 (ASN-SPBNIT OJSC North-West Telecom Autonomous System), Transit AS: AS3267 (RUNNET RUNNet) ASpath: 2895 3267 8997 ==================== Cheers, Andree From christian at broknrobot.com Tue Sep 23 01:50:48 2008 From: christian at broknrobot.com (Christian Koch) Date: Tue, 23 Sep 2008 02:50:48 -0400 Subject: prefix hijack by ASN 8997 In-Reply-To: <20080923063353.GA3558@toonk.nl> References: <20080922180658.7901E5DA@resin11.mta.everyone.net> <20080923063353.GA3558@toonk.nl> Message-ID: Ahah, so my first theory was on the right track :) Thanks for sharing the info... Christian On Tue, Sep 23, 2008 at 2:33 AM, Andree Toonk wrote: > Hi, > > .-- My secret spy satellite informs me that at Tue, 23 Sep 2008, Hank Nussbacher wrote: > >> I too spotted this via PHAS for a large number of prefixes, but have not >> received alerts from IAR, Watchmy.Net nor does RIPE RIS show this hijack: >> http://www.ris.ripe.net/perl-risapp/risearch.html I would have expected >> with so many RRC boxes that RIPE RIS would have caught it. I had thought >> it was a false positive from PHAS but now that you and others have seen >> it - I guess it is for real. > > Not a false positive, It actually was detected by the RIS box in Moscow (rrc13). Strange that it's not visible in RIS search website, but it's definitely in the raw data files. > Looking at that raw data from both routeviews and Ripe, it looks like they (AS8997) 'leaked' a full table, i.e. : > * 217.208 unique prefixes detected by the RIS server in Moscow (ASpath: 2895 3267 8997) > * 250495 seen by routeviews (ASpath: 2895 3267 8997). > (results of quick query: where AS-path contained '3267 8997' update type = advertisement). > > I'm using another prefix monitoring tool and within a few minutes it notified me of this hijack for some of our prefixes: > <> > ==================== > Prefix Hijack ( Code 11: Origin AS and Prefix changed (more specific) Or Origin AS changed) > detected 1 updates for your prefix 128.189.0.0/16 AS271: > Update details: 2008-09-22 09:33 (UTC) > 128.189.0.0/16 > Announced by: AS8997 (ASN-SPBNIT OJSC North-West Telecom Autonomous System), > Transit AS: AS3267 (RUNNET RUNNet) > ASpath: 2895 3267 8997 > ==================== > Prefix Hijack ( Code 11: Origin AS and Prefix changed (more specific) Or Origin AS changed) > detected 1 updates for your prefix 142.231.0.0/16 AS271: > Update details: 2008-09-22 09:34 (UTC) > 142.231.0.0/16 > Announced by: AS8997 (ASN-SPBNIT OJSC North-West Telecom Autonomous System), > Transit AS: AS3267 (RUNNET RUNNet) > ASpath: 2895 3267 8997 > ==================== > > > Cheers, > Andree > > From hank at efes.iucc.ac.il Tue Sep 23 01:53:17 2008 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 23 Sep 2008 09:53:17 +0300 (IDT) Subject: prefix hijack by ASN 8997 In-Reply-To: <20080923063353.GA3558@toonk.nl> References: <20080922180658.7901E5DA@resin11.mta.everyone.net> <20080923063353.GA3558@toonk.nl> Message-ID: On Tue, 23 Sep 2008, Andree Toonk wrote: > Not a false positive, It actually was detected by the RIS box in Moscow (rrc13). Strange that it's not visible in RIS search website, but it's definitely in the raw data files. > Looking at that raw data from both routeviews and Ripe, it looks like they (AS8997) 'leaked' a full table, i.e. : > * 217.208 unique prefixes detected by the RIS server in Moscow (ASpath: 2895 3267 8997) > * 250495 seen by routeviews (ASpath: 2895 3267 8997). > (results of quick query: where AS-path contained '3267 8997' update type = advertisement). > > ASpath: 2895 3267 8997 Is that the only ASpath that leaked it? There are others - did they filter properly and only that path failed to filter? Regards, Hank From andree+nanog at toonk.nl Tue Sep 23 02:24:51 2008 From: andree+nanog at toonk.nl (Andree Toonk) Date: Tue, 23 Sep 2008 09:24:51 +0200 Subject: prefix hijack by ASN 8997 In-Reply-To: References: <20080922180658.7901E5DA@resin11.mta.everyone.net> <20080923063353.GA3558@toonk.nl> Message-ID: <20080923072451.GA26259@toonk.nl> Hi Hank, .-- My secret spy satellite informs me that at Tue, 23 Sep 2008, Hank Nussbacher wrote: >> Looking at that raw data from both routeviews and Ripe, it looks like they (AS8997) 'leaked' a full table, i.e. : >> * 217.208 unique prefixes detected by the RIS server in Moscow (ASpath: 2895 3267 8997) >> * 250495 seen by routeviews (ASpath: 2895 3267 8997). >> (results of quick query: where AS-path contained '3267 8997' update type = advertisement). >> >> ASpath: 2895 3267 8997 > > Is that the only ASpath that leaked it? There are others - did they > filter properly and only that path failed to filter? Again: * 217.208 unique prefixes detected by the RIS server in Moscow (ASpath: 2895 3267 8997 & ASpath 2895 5431 3267 8997) * 250495 seen by routeviews (ASpath: 3277 3267 8997). Looks like those are the only ones, but this is just a quick egrep, awk, and sort on the rawdata so I might have missed something (It's getting late here, so no guarantees ;)) Cheers, Andree From if at xip.at Tue Sep 23 05:34:10 2008 From: if at xip.at (Ingo Flaschberger) Date: Tue, 23 Sep 2008 12:34:10 +0200 (CEST) Subject: prefix hijack by ASN 8997 In-Reply-To: <20080923072451.GA26259@toonk.nl> References: <20080922180658.7901E5DA@resin11.mta.everyone.net> <20080923063353.GA3558@toonk.nl> <20080923072451.GA26259@toonk.nl> Message-ID: Hi, http://www.msk-ix.ru/network/traffic.html it was 12:00 moscow local time. Kind regards, ingo flaschberger From if at xip.at Tue Sep 23 05:38:59 2008 From: if at xip.at (Ingo Flaschberger) Date: Tue, 23 Sep 2008 12:38:59 +0200 (CEST) Subject: prefix hijack by ASN 8997 In-Reply-To: References: <20080922180658.7901E5DA@resin11.mta.everyone.net> <20080923063353.GA3558@toonk.nl> <20080923072451.GA26259@toonk.nl> Message-ID: Hi > http://www.msk-ix.ru/network/traffic.html > it was 12:00 moscow local time. sorry, 13:xx TIME: 09/22/08 09:30:05 TYPE: BGP4MP/MESSAGE/Update FROM: 193.232.244.36 AS2895 TO: 193.232.244.114 AS12654 ORIGIN: IGP ASPATH: 2895 3267 8997 NEXT_HOP: 193.232.244.36 ANNOUNCE GMT+4 Kind regards, ingo flaschberger From tme at multicasttech.com Tue Sep 23 06:51:36 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Tue, 23 Sep 2008 07:51:36 -0400 Subject: prefix hijack by ASN 8997 In-Reply-To: <20080922180658.7901E5DA@resin11.mta.everyone.net> References: <20080922180658.7901E5DA@resin11.mta.everyone.net> Message-ID: <7CA98E5B-5044-4445-BE2F-018C48BC1604@multicasttech.com> On Sep 22, 2008, at 9:06 PM, Scott Weeks wrote: > > > > I am hoping to confirm a short-duration prefix hijack of > 72.234.0.0/15 (and another of our prefixes) by ASN 8997 ("OJSC North- > West Telecom" in Russia) in using ASN 3267 (Russian Federal > University Network) to advertise our space to ASN 3277 (Regional > University and Scientific Network (RUSNet) of North-Western and > Saint-Petersburg Area of Russia). > > Is that what I'm seeing when I go to "bgplay.routeviews.org/bgplay", > put in prefix 72.234.0.0/15 and select the dates: > > 22/9/2008 9:00:00 and 22/9/2008 15:00:00 > > If so, am I understanding it correctly if I say ASN 3267 saw a > shorter path from ASN 8997, so refused the proper announcement from > ASN 36149 (me) it normally hears from ASN 174 (Cogent). I cannot confirm that from the monitoring program at AS 16517 : [tme at lennon mcast]$ grep 72.234.0.0 bgp.full.Sep_2*2008 bgp.full.Sep_21_00:07:00_EDT_2008:*> 72.234.0.0/15 38.101.161.116 3990 0 174 209 36149 ? bgp.full.Sep_21_06:07:00_EDT_2008:*> 72.234.0.0/15 38.101.161.116 3990 0 174 209 36149 ? bgp.full.Sep_21_12:07:00_EDT_2008:*> 72.234.0.0/15 38.101.161.116 3990 0 174 209 36149 ? bgp.full.Sep_21_18:07:00_EDT_2008:*> 72.234.0.0/15 38.101.161.116 3990 0 174 209 36149 ? bgp.full.Sep_22_00:07:00_EDT_2008:*> 72.234.0.0/15 38.101.161.116 3990 0 174 209 36149 ? bgp.full.Sep_22_06:07:00_EDT_2008:*> 72.234.0.0/15 38.101.161.116 3990 0 174 209 36149 ? bgp.full.Sep_22_12:07:00_EDT_2008:*> 72.234.0.0/15 38.101.161.116 3990 0 174 209 36149 ? bgp.full.Sep_22_18:07:00_EDT_2008:*> 72.234.0.0/15 38.101.161.116 3990 0 174 209 36149 ? bgp.full.Sep_23_00:07:00_EDT_2008:*> 72.234.0.0/15 38.101.161.116 3990 0 174 209 36149 ? bgp.full.Sep_23_06:07:00_EDT_2008:*> 72.234.0.0/15 38.101.161.116 3990 0 174 209 36149 ? You didn't specify the time zone you are in, so I looked at +- 1 day around it. If the hijack lasted 6 hours, we should have seen it. Regards Marshall > > > If the above two are correct, would it be correct to say only the > downstream customers of ASN 3267 were affected? > > scott > From surfer at mauigateway.com Tue Sep 23 07:15:50 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 23 Sep 2008 05:15:50 -0700 Subject: prefix hijack by ASN 8997 Message-ID: <20080923051550.7901BA2F@resin11.mta.everyone.net> --- tme at multicasttech.com wrote: From: Marshall Eubanks : You didn't specify the time zone you are in, : so I looked at +- 1 day around it. If the : hijack lasted 6 hours, we should have seen it. My apologies, I just used the time zone the tool (bgplay.routeviews.org/bgplay) was using when I said: 22/9/2008 9:00:00 and 22/9/2008 15:00:00 I'm sure it was in GMT. Seeing the many responses, we now know something happened and it was only about 15 minutes in duration. bgplay shows the problem with the above data and I was just wondering if I was understanding the impact correctly: > If the above two are correct, would it be > correct to say only the downstream customers > of ASN 3267 were affected? I was not following the rules properly: never attribute to malice that which can be explained by human error. I thought there might be some testing-of-the-water in preparation for future 'events' and I guess I was starting to be trigger happy after all the talk about the new BGP attack. scott --- tme at multicasttech.com wrote: From: Marshall Eubanks To: surfer at mauigateway.com Cc: Subject: Re: prefix hijack by ASN 8997 Date: Tue, 23 Sep 2008 07:51:36 -0400 On Sep 22, 2008, at 9:06 PM, Scott Weeks wrote: > > > > I am hoping to confirm a short-duration prefix hijack of > 72.234.0.0/15 (and another of our prefixes) by ASN 8997 ("OJSC North- > West Telecom" in Russia) in using ASN 3267 (Russian Federal > University Network) to advertise our space to ASN 3277 (Regional > University and Scientific Network (RUSNet) of North-Western and > Saint-Petersburg Area of Russia). > > Is that what I'm seeing when I go to "bgplay.routeviews.org/bgplay", > put in prefix 72.234.0.0/15 and select the dates: > > 22/9/2008 9:00:00 and 22/9/2008 15:00:00 > > If so, am I understanding it correctly if I say ASN 3267 saw a > shorter path from ASN 8997, so refused the proper announcement from > ASN 36149 (me) it normally hears from ASN 174 (Cogent). I cannot confirm that from the monitoring program at AS 16517 : [tme at lennon mcast]$ grep 72.234.0.0 bgp.full.Sep_2*2008 bgp.full.Sep_21_00:07:00_EDT_2008:*> 72.234.0.0/15 38.101.161.116 3990 0 174 209 36149 ? bgp.full.Sep_21_06:07:00_EDT_2008:*> 72.234.0.0/15 38.101.161.116 3990 0 174 209 36149 ? bgp.full.Sep_21_12:07:00_EDT_2008:*> 72.234.0.0/15 38.101.161.116 3990 0 174 209 36149 ? bgp.full.Sep_21_18:07:00_EDT_2008:*> 72.234.0.0/15 38.101.161.116 3990 0 174 209 36149 ? bgp.full.Sep_22_00:07:00_EDT_2008:*> 72.234.0.0/15 38.101.161.116 3990 0 174 209 36149 ? bgp.full.Sep_22_06:07:00_EDT_2008:*> 72.234.0.0/15 38.101.161.116 3990 0 174 209 36149 ? bgp.full.Sep_22_12:07:00_EDT_2008:*> 72.234.0.0/15 38.101.161.116 3990 0 174 209 36149 ? bgp.full.Sep_22_18:07:00_EDT_2008:*> 72.234.0.0/15 38.101.161.116 3990 0 174 209 36149 ? bgp.full.Sep_23_00:07:00_EDT_2008:*> 72.234.0.0/15 38.101.161.116 3990 0 174 209 36149 ? bgp.full.Sep_23_06:07:00_EDT_2008:*> 72.234.0.0/15 38.101.161.116 3990 0 174 209 36149 ? You didn't specify the time zone you are in, so I looked at +- 1 day around it. If the hijack lasted 6 hours, we should have seen it. Regards Marshall > > > If the above two are correct, would it be correct to say only the > downstream customers of ASN 3267 were affected? > > scott > From cchurc05 at harris.com Tue Sep 23 08:00:44 2008 From: cchurc05 at harris.com (Church, Charles) Date: Tue, 23 Sep 2008 08:00:44 -0500 Subject: prefix hijack by ASN 8997 In-Reply-To: References: <20080922180658.7901E5DA@resin11.mta.everyone.net><48D87015.4030802@justinshore.com> Message-ID: Agree on #2 as well. You can bet they're also reading Nanog right now to see who and how it was detected. Oh, well, on with the fight. Chuck -----Original Message----- From: Christian Koch [mailto:christian at broknrobot.com] Sent: Tuesday, September 23, 2008 12:58 AM To: Justin Shore; surfer at mauigateway.com; nanog at merit.edu Subject: Re: prefix hijack by ASN 8997 At first glance this morning not seeing any data between the gain and lost alerts from phas and inability to find a route in any of the many collectors and route servers out there I had thought it was a possibly a fat finger mistake by 8997 or a false positive. After locating the data in bgplay/rviews, and noticing how many more people this occured to I'm leaning towards 2 possible scenarios: 1 - bgp misconfigurations leading to leaks (Depends on the overall scale of how many other prefixes were possibly announced) 2 - 8997 began announcing prefixes as an experiment to "test the waters" for potential real hijacks in future... 'geography' hints towards #2 Or both theories could be way off :) I'd be interested to know if Renesys collected any data that might give some better insight to this... Christian On 9/23/08, Justin Shore wrote: > Looking up some of my prefixes in PHAS and BGPPlay, I too see my > prefixes being advertised by 8997 for a short time. It looks like it > happened around 1222091563 according to PHAS. > > Was this a mistake or something else? > > Justin > > > Christian Koch wrote: >> I received a phas notification about this today as well... >> >> I couldn't find any relevant data confirming the announcement of one >> of my /19 blocks, until a few minutes ago when i checked the route >> views bgplay (ripe bgplay turns up nothing) and can now see 8997 >> announcing and quickly withdrawing my prefix >> >> >> >> >> On Mon, Sep 22, 2008 at 9:06 PM, Scott Weeks >> wrote: >>> >>> >>> I am hoping to confirm a short-duration prefix hijack of 72.234.0.0/15 >>> (and another of our prefixes) by ASN 8997 ("OJSC North-West Telecom" in >>> Russia) in using ASN 3267 (Russian Federal University Network) to >>> advertise our space to ASN 3277 (Regional University and Scientific >>> Network (RUSNet) of North-Western and Saint-Petersburg Area of Russia). >>> >>> Is that what I'm seeing when I go to "bgplay.routeviews.org/bgplay", put >>> in prefix 72.234.0.0/15 and select the dates: >>> >>> 22/9/2008 9:00:00 and 22/9/2008 15:00:00 >>> >>> If so, am I understanding it correctly if I say ASN 3267 saw a shorter >>> path from ASN 8997, so refused the proper announcement from ASN 36149 >>> (me) it normally hears from ASN 174 (Cogent). >>> >>> If the above two are correct, would it be correct to say only the >>> downstream customers of ASN 3267 were affected? >>> >>> scott >>> >>> >> > -- Sent from my mobile device From surfer at mauigateway.com Tue Sep 23 08:08:46 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 23 Sep 2008 06:08:46 -0700 Subject: comparison of hijack alert systems [was]: prefix hijack by ASN 8997 Message-ID: <20080923060846.7901A232@resin11.mta.everyone.net> On Mon, 22 Sep 2008, Scott Weeks wrote: > > I am hoping to confirm a short-duration prefix hijack --- hank at efes.iucc.ac.il wrote: From: Hank Nussbacher I too spotted this via PHAS for a large number of prefixes, but have not received alerts from IAR, Watchmy.Net nor does RIPE RIS show this hijack: http://www.ris.ripe.net/perl-risapp/risearch.html I would have expected with so many RRC boxes that RIPE RIS would have caught it. I had thought it was a false positive from PHAS but now that you and others have seen it - I guess it is for real. ---------------------------------------- It'd be very interesting to compare said systems using this event. I have not subscribed to MyASN or watchmy.net yet, so I can't do that. I do note, however, that PHAS took 4 hours and 20 minutes to email me, which is within the specs noted on their site. scott From justin at justinshore.com Tue Sep 23 09:17:53 2008 From: justin at justinshore.com (Justin Shore) Date: Tue, 23 Sep 2008 09:17:53 -0500 Subject: InterCage, Inc. (NOT Atrivo) In-Reply-To: <66536.1222132029@turing-police.cc.vt.edu> References: <20080908112049.256D9BBE@resin13.mta.everyone.net> <200809110850.25652.lowen@pari.edu> <5D20455D-01B1-4406-AAEE-FFD9654DDF59@ianai.net> <48D81582.2030904@justinshore.com> <66536.1222132029@turing-police.cc.vt.edu> Message-ID: <48D8FA91.70000@justinshore.com> Valdis.Kletnieks at vt.edu wrote: > On Mon, 22 Sep 2008 17:00:35 CDT, Justin Shore said: > >> There may not be a law preventing you from asking him for proof of >> legitimate customers, but there is a law preventing him from answering >> you. Google for CPNI and "red flag". > > Hmm... I'm not sure how "Yes, XYZ is a customer of mine" qualifies as > a "red flag" question for identity theft. I'm also not sure how "XYZ is > a customer" qualifies as CPNI, which (according to the first few pages of > Google hits) comprises things like calling/billing records. > > Nope. Doesn't seem like "xyz is a customer" qualifies there... > > Hmm... "xyz is a customer" doesn't seem to run afoul of that either. > > Feel free to enlighten me about what I missed here? Given the unfortunate vagueness of the FCC on their directive, consultants have interpreted CPNI differently and have given their customers (SP and CS organizations) wildly varying instructions. However every interpretation that I've been privy to extends far beyond call records like many people believe CPNI is limited to. Our CPNI consultants instructed us to not even reveal that Company X is a customer (which is laughable given the size of the communities we serve, but I digress). They did however tell us that we can trust all phone numbers listed on an account both for instant information providing and for callbacks. Cox's interpretation is that only the primary number listed on the account is valid for callbacks and that the PIN is required regardless (something our consultants told us was only required if the caller couldn't be reached on a valid callback number). Everybody has different instructions to work with. To answer the question the list is asking, the SP isn't simply stating that Company X is a customer of SP ABC. They are stating that Company X is a customer and that they believe Company X is a valid, not malicious customer in good standing. While that's not a call record that implies certain things about Company X's relationship with the SP. They essentially stating that they haven't received spam or other abuse complaints regarding the customer. They're implying that they are a customer in good standing. That could even be construed to imply that their account is in good standing. That's more than just saying that Company X is a customer of SP ABC. Our consultants advised us against saying anything of the sort. Think of it like HIPAA for SPs. It's splitting hairs but that's the unfortunate situation that CPNI has put all of us in. Instead of a common sense response we get to deal with the knee-jerk response from the FCC thanks chiefly to the Patty Dunn scandal. Justin From jgreco at ns.sol.net Tue Sep 23 09:39:13 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 23 Sep 2008 09:39:13 -0500 (CDT) Subject: Atrivo/Intercage In-Reply-To: from "Drew Linsalata" at Sep 22, 2008 04:48:16 PM Message-ID: <200809231439.m8NEdDqj091836@aurora.sol.net> > On Sep 22, 2008, at 4:33 PM, Tom Sparks (Applied Operations) wrote: > > Intercage is not a big shop, there are very few people involved in > > running it > > I have no dog in this fight, but I would comment on the "small shop" > issue as it relates to handling abuse complaints. > > I own a small colo/hosting shop too. We don't have many employees. > If we had to deal with so many abuse complaints that things were > "getting lost in the noise", I'd have to seriously examine my AUP and > associated enforcement policies, add staff to handle abuse issues, or > both. Being small isn't an excuse. In fact, a small shop that runs a > clean network should be far better at handling abuse issues than the > larger players could ever hope to be. I would have to agree with this latter bit. We count incidents per YEAR. On a hand. Mostly because we haven't made a habit of accepting random clients, I guess, but were it a problem, it would be made not to be. Being proactive is a big part of this. For example, when ARIN began to allow abuse contacts for IP space, we fairly quickly registered a POC for 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 tme at multicasttech.com Tue Sep 23 10:39:14 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Tue, 23 Sep 2008 11:39:14 -0400 Subject: prefix hijack by ASN 8997 In-Reply-To: <20080923051550.7901BA2F@resin11.mta.everyone.net> References: <20080923051550.7901BA2F@resin11.mta.everyone.net> Message-ID: On Sep 23, 2008, at 8:15 AM, Scott Weeks wrote: > > > --- tme at multicasttech.com wrote: > From: Marshall Eubanks > > : You didn't specify the time zone you are in, > : so I looked at +- 1 day around it. If the > : hijack lasted 6 hours, we should have seen it. > > My apologies, I just used the time zone the tool > (bgplay.routeviews.org/bgplay) was using when I said: > 22/9/2008 9:00:00 and 22/9/2008 15:00:00 > > I'm sure it was in GMT. Seeing the many responses, we now know > something happened and it was only about 15 minutes in duration. These two times are separated by 6 hours exactly (0500 and 1100 EDT). There is a positive report at 1330 Moscow time or 0930 UTC or 0530 EDT. There is a positive report "a few minutes" before 0122 UTC - say 0115 There is a positive report at 1222091563 which I cannot interpret. (1222 UTC ?) We have my negative reports at 0607 EDT and 1207 EDT, etc., or 1007 UTC and 1607 UTC, etc. So (all times UTC) 0407 no 0900 yes 0930 yes 1007 no 1500 yes 1607 no 2207 no 0115 yes 0407 no So, do you think this was lots of little tests / hijacks / mistakes ? Or did it just not propagate very far ? Marshall > > bgplay shows the problem with the above data and I was just > wondering if I was understanding the impact correctly: > >> If the above two are correct, would it be >> correct to say only the downstream customers >> of ASN 3267 were affected? > > I was not following the rules properly: never attribute to malice > that which can be explained by human error. I thought there might > be some testing-of-the-water in preparation for future 'events' and > I guess I was starting to be trigger happy after all the talk about > the new BGP attack. > > scott > > > > > --- tme at multicasttech.com wrote: > > From: Marshall Eubanks > To: surfer at mauigateway.com > Cc: > Subject: Re: prefix hijack by ASN 8997 > Date: Tue, 23 Sep 2008 07:51:36 -0400 > > > On Sep 22, 2008, at 9:06 PM, Scott Weeks wrote: > >> >> >> >> I am hoping to confirm a short-duration prefix hijack of >> 72.234.0.0/15 (and another of our prefixes) by ASN 8997 ("OJSC North- >> West Telecom" in Russia) in using ASN 3267 (Russian Federal >> University Network) to advertise our space to ASN 3277 (Regional >> University and Scientific Network (RUSNet) of North-Western and >> Saint-Petersburg Area of Russia). >> >> Is that what I'm seeing when I go to "bgplay.routeviews.org/bgplay", >> put in prefix 72.234.0.0/15 and select the dates: >> >> 22/9/2008 9:00:00 and 22/9/2008 15:00:00 >> >> If so, am I understanding it correctly if I say ASN 3267 saw a >> shorter path from ASN 8997, so refused the proper announcement from >> ASN 36149 (me) it normally hears from ASN 174 (Cogent). > > I cannot confirm that from the monitoring program at AS 16517 : > > [tme at lennon mcast]$ grep 72.234.0.0 bgp.full.Sep_2*2008 > bgp.full.Sep_21_00:07:00_EDT_2008:*> 72.234.0.0/15 > 38.101.161.116 3990 0 174 209 36149 ? > bgp.full.Sep_21_06:07:00_EDT_2008:*> 72.234.0.0/15 > 38.101.161.116 3990 0 174 209 36149 ? > bgp.full.Sep_21_12:07:00_EDT_2008:*> 72.234.0.0/15 > 38.101.161.116 3990 0 174 209 36149 ? > bgp.full.Sep_21_18:07:00_EDT_2008:*> 72.234.0.0/15 > 38.101.161.116 3990 0 174 209 36149 ? > bgp.full.Sep_22_00:07:00_EDT_2008:*> 72.234.0.0/15 > 38.101.161.116 3990 0 174 209 36149 ? > bgp.full.Sep_22_06:07:00_EDT_2008:*> 72.234.0.0/15 > 38.101.161.116 3990 0 174 209 36149 ? > bgp.full.Sep_22_12:07:00_EDT_2008:*> 72.234.0.0/15 > 38.101.161.116 3990 0 174 209 36149 ? > bgp.full.Sep_22_18:07:00_EDT_2008:*> 72.234.0.0/15 > 38.101.161.116 3990 0 174 209 36149 ? > bgp.full.Sep_23_00:07:00_EDT_2008:*> 72.234.0.0/15 > 38.101.161.116 3990 0 174 209 36149 ? > bgp.full.Sep_23_06:07:00_EDT_2008:*> 72.234.0.0/15 > 38.101.161.116 3990 0 174 209 36149 ? > > You didn't specify the time zone you are in, so I looked at +- 1 day > around it. If the hijack lasted 6 hours, we > should have seen it. > > Regards > Marshall > > >> >> >> If the above two are correct, would it be correct to say only the >> downstream customers of ASN 3267 were affected? >> >> scott >> > > > > From source_route at yahoo.com Tue Sep 23 10:43:06 2008 From: source_route at yahoo.com (Philip Lavine) Date: Tue, 23 Sep 2008 08:43:06 -0700 (PDT) Subject: eigrp and managed ethernet Message-ID: <520409.69934.qm@web30806.mail.mud.yahoo.com> For some reason when I lose layer 3 connectivity between two managed Ethernet sites EIGRP does not bounce.Is this because the physical interface does not bounce? From surfer at mauigateway.com Tue Sep 23 10:54:21 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 23 Sep 2008 08:54:21 -0700 Subject: prefix hijack by ASN 8997 Message-ID: <20080923085421.79007543@resin11.mta.everyone.net> ------ tme at multicasttech.com wrote: ---------- From: Marshall Eubanks So, do you think this was lots of little tests / hijacks / mistakes ? Or did it just not propagate very far ? --------------------------------------------- According to Andree Toonk (and someone confirmed privately) ASN 8997 leaked a full table to ASN 3267 (who didn't filter!). The only upstream of ASN 3267 I saw in bgplay was ASN 174 (Cogent) who seems to have filtered, but I can't confirm. So I guess that the impact would've only been to the peers downstream of ASN 3267. scott --------------------------------------------- Andree Toonk Not a false positive, It actually was detected by the RIS box in Moscow (rrc13). Strange that it's not visible in RIS search website, but it's definitely in the raw data files. Looking at that raw data from both routeviews and Ripe, it looks like they (AS8997) 'leaked' a full table, i.e. : ---------------------------------------------- From mhuff at ox.com Tue Sep 23 10:59:14 2008 From: mhuff at ox.com (Matthew Huff) Date: Tue, 23 Sep 2008 11:59:14 -0400 Subject: eigrp and managed ethernet In-Reply-To: <520409.69934.qm@web30806.mail.mud.yahoo.com> References: <520409.69934.qm@web30806.mail.mud.yahoo.com> Message-ID: <483E6B0272B0284BA86D7596C40D29F9142CD00890@PUR-EXCH07.ox.com> Correct. Eigrp neighbor connectivity has a short-cut when L2 connectivity goes down, otherwise it will use the eigrp neighbor hold-down timer. You can decrease that timer: interface fa0/0 ip hello-interval eigrp p x ip hold-time eigrp p y where p is your eigrp as-number, and x is how often you want the hello (in seconds) and y is the max hold-down timer. Generally y is = x * 3 http://www.cisco.com/en/US/docs/ios/12_2/iproute/command/reference/1rfeigrp.html ---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 -----Original Message----- From: Philip Lavine [mailto:source_route at yahoo.com] Sent: Tuesday, September 23, 2008 11:43 AM To: nanog Subject: eigrp and managed ethernet For some reason when I lose layer 3 connectivity between two managed Ethernet sites EIGRP does not bounce.Is this because the physical interface does not bounce? From tme at multicasttech.com Tue Sep 23 11:03:54 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Tue, 23 Sep 2008 12:03:54 -0400 Subject: prefix hijack by ASN 8997 In-Reply-To: <20080923085421.79007543@resin11.mta.everyone.net> References: <20080923085421.79007543@resin11.mta.everyone.net> Message-ID: <41836CA9-9C5B-4639-B5CB-B40B28471315@multicasttech.com> Note that my bgp was through Cogent - my guess is they did filter. Marshall On Sep 23, 2008, at 11:54 AM, Scott Weeks wrote: > > ------ tme at multicasttech.com wrote: ---------- > From: Marshall Eubanks > > So, do you think this was lots of little tests / hijacks / mistakes ? > Or did it just not propagate very far ? > --------------------------------------------- > > According to Andree Toonk (and someone confirmed privately) ASN 8997 > leaked a full table to ASN 3267 (who didn't filter!). The only > upstream of ASN 3267 I saw in bgplay was ASN 174 (Cogent) who seems > to have filtered, but I can't confirm. So I guess that the impact > would've only been to the peers downstream of ASN 3267. > > scott > > > > > > --------------------------------------------- > Andree Toonk > > Not a false positive, It actually was detected by the RIS box in > Moscow > (rrc13). Strange that it's not visible in RIS search website, but it's > definitely in the raw data files. > Looking at that raw data from both routeviews and Ripe, it looks like > they (AS8997) 'leaked' a full table, i.e. : > ---------------------------------------------- > From luan at netcraftsmen.net Tue Sep 23 11:07:45 2008 From: luan at netcraftsmen.net (Luan Nguyen) Date: Tue, 23 Sep 2008 12:07:45 -0400 Subject: eigrp and managed ethernet In-Reply-To: <520409.69934.qm@web30806.mail.mud.yahoo.com> References: <520409.69934.qm@web30806.mail.mud.yahoo.com> Message-ID: <02e801c91d96$8416b3b0$8c441b10$@net> Yeah. If the link-layer failure is hidden from your routing protocol, then the routing protocol has to rely on its timer setting. When your EIGRP's hold-time expires, peering would bounce. Luan -----Original Message----- From: Philip Lavine [mailto:source_route at yahoo.com] Sent: Tuesday, September 23, 2008 11:43 AM To: nanog Subject: eigrp and managed Ethernet For some reason when I lose layer 3 connectivity between two managed Ethernet sites EIGRP does not bounce.Is this because the physical interface does not bounce? From kratzers at pa.net Tue Sep 23 11:07:55 2008 From: kratzers at pa.net (Stephen Kratzer) Date: Tue, 23 Sep 2008 12:07:55 -0400 Subject: eigrp and managed ethernet In-Reply-To: <520409.69934.qm@web30806.mail.mud.yahoo.com> References: <520409.69934.qm@web30806.mail.mud.yahoo.com> Message-ID: <200809231207.55872.kratzers@pa.net> On Tuesday 23 September 2008 11:43:06 Philip Lavine wrote: > For some reason when I lose layer 3 connectivity between two managed > Ethernet sites EIGRP does not bounce.Is this because the physical interface > does not bounce? Because EIGRP hellos are sent via IP multicast, layer 3 connectivity is required to establish and maintain adjacencies. However, layer 3 failures aren't detected for, at most, 15 seconds by default on an Ethernet link. Stephen Kratzer Network Engineer CTI Networks, Inc. From kratzers at pa.net Tue Sep 23 11:07:55 2008 From: kratzers at pa.net (Stephen Kratzer) Date: Tue, 23 Sep 2008 12:07:55 -0400 Subject: eigrp and managed ethernet In-Reply-To: <520409.69934.qm@web30806.mail.mud.yahoo.com> References: <520409.69934.qm@web30806.mail.mud.yahoo.com> Message-ID: <200809231207.55872.kratzers@pa.net> On Tuesday 23 September 2008 11:43:06 Philip Lavine wrote: > For some reason when I lose layer 3 connectivity between two managed > Ethernet sites EIGRP does not bounce.Is this because the physical interface > does not bounce? Because EIGRP hellos are sent via IP multicast, layer 3 connectivity is required to establish and maintain adjacencies. However, layer 3 failures aren't detected for, at most, 15 seconds by default on an Ethernet link. Stephen Kratzer Network Engineer CTI Networks, Inc. From source_route at yahoo.com Tue Sep 23 11:25:34 2008 From: source_route at yahoo.com (Philip Lavine) Date: Tue, 23 Sep 2008 09:25:34 -0700 (PDT) Subject: eigrp and managed ethernet Message-ID: <542140.85408.qm@web30802.mail.mud.yahoo.com> What is really bizarre is that I am down for minutes not seconds and the timers never fire. If I don't manually passive the connection eigrp will for some reason think there is a neighbor even though I am unable to source ping across the WAN. ----- Original Message ---- From: Matthew Huff To: Philip Lavine ; nanog Sent: Tuesday, September 23, 2008 8:59:14 AM Subject: RE: eigrp and managed ethernet Correct. Eigrp neighbor connectivity has a short-cut when L2 connectivity goes down, otherwise it will use the eigrp neighbor hold-down timer. You can decrease that timer: interface fa0/0 ip hello-interval eigrp p x ip hold-time eigrp p y where p is your eigrp as-number, and x is how often you want the hello (in seconds) and y is the max hold-down timer. Generally y is = x * 3 http://www.cisco.com/en/US/docs/ios/12_2/iproute/command/reference/1rfeigrp.html ---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 -----Original Message----- From: Philip Lavine [mailto:source_route at yahoo.com] Sent: Tuesday, September 23, 2008 11:43 AM To: nanog Subject: eigrp and managed ethernet For some reason when I lose layer 3 connectivity between two managed Ethernet sites EIGRP does not bounce.Is this because the physical interface does not bounce? From Jeremy_Lunsford at playstation.sony.com Tue Sep 23 11:32:09 2008 From: Jeremy_Lunsford at playstation.sony.com (Jeremy_Lunsford at playstation.sony.com) Date: Tue, 23 Sep 2008 09:32:09 -0700 Subject: eigrp and managed ethernet In-Reply-To: <542140.85408.qm@web30802.mail.mud.yahoo.com> Message-ID: Are you 100% positive that the link is really not passing any traffic? Have you looked at interface stats to verify that there are no incoming packets? I'd suggest running some EIGRP debug commands during the outage to verify if you are really not getting any packets.. Philip Lavine 09/23/2008 09:25 AM To nanog cc Subject Re: eigrp and managed ethernet What is really bizarre is that I am down for minutes not seconds and the timers never fire. If I don't manually passive the connection eigrp will for some reason think there is a neighbor even though I am unable to source ping across the WAN. ----- Original Message ---- From: Matthew Huff To: Philip Lavine ; nanog Sent: Tuesday, September 23, 2008 8:59:14 AM Subject: RE: eigrp and managed ethernet Correct. Eigrp neighbor connectivity has a short-cut when L2 connectivity goes down, otherwise it will use the eigrp neighbor hold-down timer. You can decrease that timer: interface fa0/0 ip hello-interval eigrp p x ip hold-time eigrp p y where p is your eigrp as-number, and x is how often you want the hello (in seconds) and y is the max hold-down timer. Generally y is = x * 3 http://www.cisco.com/en/US/docs/ios/12_2/iproute/command/reference/1rfeigrp.html ---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 -----Original Message----- From: Philip Lavine [mailto:source_route at yahoo.com] Sent: Tuesday, September 23, 2008 11:43 AM To: nanog Subject: eigrp and managed ethernet For some reason when I lose layer 3 connectivity between two managed Ethernet sites EIGRP does not bounce.Is this because the physical interface does not bounce? From bknoll at 7ticks.com Tue Sep 23 11:33:52 2008 From: bknoll at 7ticks.com (Brian Knoll) Date: Tue, 23 Sep 2008 09:33:52 -0700 Subject: eigrp and managed ethernet In-Reply-To: <542140.85408.qm@web30802.mail.mud.yahoo.com> References: <542140.85408.qm@web30802.mail.mud.yahoo.com> Message-ID: <5B694462F050EB45A4B7B9A0302DC5FE377062A85E@EXVMBX017-10.exch017.msoutlookonline.net> The issue may be that only one direction of traffic is being impacted. So maybe your A end is receiving all the hellos, while the Z end is not. Therefore A still has Z as a neighbor, but Z doesn't have A as a neighbor. Brian Knoll -----Original Message----- From: Philip Lavine [mailto:source_route at yahoo.com] Sent: Tuesday, September 23, 2008 11:26 AM To: nanog Subject: Re: eigrp and managed ethernet What is really bizarre is that I am down for minutes not seconds and the timers never fire. If I don't manually passive the connection eigrp will for some reason think there is a neighbor even though I am unable to source ping across the WAN. ----- Original Message ---- From: Matthew Huff To: Philip Lavine ; nanog Sent: Tuesday, September 23, 2008 8:59:14 AM Subject: RE: eigrp and managed ethernet Correct. Eigrp neighbor connectivity has a short-cut when L2 connectivity goes down, otherwise it will use the eigrp neighbor hold-down timer. You can decrease that timer: interface fa0/0 ip hello-interval eigrp p x ip hold-time eigrp p y where p is your eigrp as-number, and x is how often you want the hello (in seconds) and y is the max hold-down timer. Generally y is = x * 3 http://www.cisco.com/en/US/docs/ios/12_2/iproute/command/reference/1rfeigrp.html ---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 -----Original Message----- From: Philip Lavine [mailto:source_route at yahoo.com] Sent: Tuesday, September 23, 2008 11:43 AM To: nanog Subject: eigrp and managed ethernet For some reason when I lose layer 3 connectivity between two managed Ethernet sites EIGRP does not bounce.Is this because the physical interface does not bounce? From kratzers at pa.net Tue Sep 23 11:48:50 2008 From: kratzers at pa.net (Stephen Kratzer) Date: Tue, 23 Sep 2008 12:48:50 -0400 Subject: eigrp and managed ethernet In-Reply-To: <542140.85408.qm@web30802.mail.mud.yahoo.com> References: <542140.85408.qm@web30802.mail.mud.yahoo.com> Message-ID: <200809231248.50864.kratzers@pa.net> Be sure to differentiate between unicast and multicast reachability. Try 'ping 224.0.0.10'. Stephen Kratzer On Tuesday 23 September 2008 12:25:34 Philip Lavine wrote: > What is really bizarre is that I am down for minutes not seconds and the > timers never fire. If I don't manually passive the connection eigrp will > for some reason think there is a neighbor even though I am unable to source > ping across the WAN. > > > > ----- Original Message ---- > From: Matthew Huff > To: Philip Lavine ; nanog > Sent: Tuesday, September 23, 2008 8:59:14 AM > Subject: RE: eigrp and managed ethernet > > Correct. Eigrp neighbor connectivity has a short-cut when L2 connectivity > goes down, otherwise it will use the eigrp neighbor hold-down timer. You > can decrease that timer: > > interface fa0/0 > ip hello-interval eigrp p x > ip hold-time eigrp p y > > where p is your eigrp as-number, and x is how often you want the hello (in > seconds) and y is the max hold-down timer. Generally y is = x * 3 > > http://www.cisco.com/en/US/docs/ios/12_2/iproute/command/reference/1rfeigrp >.html > > > ---- > Matthew Huff | One Manhattanville Rd > OTA Management LLC | Purchase, NY 10577 > www.ox.com | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-460-4139 > > -----Original Message----- > From: Philip Lavine [mailto:source_route at yahoo.com] > Sent: Tuesday, September 23, 2008 11:43 AM > To: nanog > Subject: eigrp and managed ethernet > > For some reason when I lose layer 3 connectivity between two managed > Ethernet sites EIGRP does not bounce.Is this because the physical interface > does not bounce? From kratzers at pa.net Tue Sep 23 11:48:50 2008 From: kratzers at pa.net (Stephen Kratzer) Date: Tue, 23 Sep 2008 12:48:50 -0400 Subject: eigrp and managed ethernet In-Reply-To: <542140.85408.qm@web30802.mail.mud.yahoo.com> References: <542140.85408.qm@web30802.mail.mud.yahoo.com> Message-ID: <200809231248.50864.kratzers@pa.net> Be sure to differentiate between unicast and multicast reachability. Try 'ping 224.0.0.10'. Stephen Kratzer On Tuesday 23 September 2008 12:25:34 Philip Lavine wrote: > What is really bizarre is that I am down for minutes not seconds and the > timers never fire. If I don't manually passive the connection eigrp will > for some reason think there is a neighbor even though I am unable to source > ping across the WAN. > > > > ----- Original Message ---- > From: Matthew Huff > To: Philip Lavine ; nanog > Sent: Tuesday, September 23, 2008 8:59:14 AM > Subject: RE: eigrp and managed ethernet > > Correct. Eigrp neighbor connectivity has a short-cut when L2 connectivity > goes down, otherwise it will use the eigrp neighbor hold-down timer. You > can decrease that timer: > > interface fa0/0 > ip hello-interval eigrp p x > ip hold-time eigrp p y > > where p is your eigrp as-number, and x is how often you want the hello (in > seconds) and y is the max hold-down timer. Generally y is = x * 3 > > http://www.cisco.com/en/US/docs/ios/12_2/iproute/command/reference/1rfeigrp >.html > > > ---- > Matthew Huff | One Manhattanville Rd > OTA Management LLC | Purchase, NY 10577 > www.ox.com | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-460-4139 > > -----Original Message----- > From: Philip Lavine [mailto:source_route at yahoo.com] > Sent: Tuesday, September 23, 2008 11:43 AM > To: nanog > Subject: eigrp and managed ethernet > > For some reason when I lose layer 3 connectivity between two managed > Ethernet sites EIGRP does not bounce.Is this because the physical interface > does not bounce? From kevin.hodle at gmail.com Tue Sep 23 11:59:14 2008 From: kevin.hodle at gmail.com (Kevin Hodle) Date: Tue, 23 Sep 2008 11:59:14 -0500 Subject: eigrp and managed ethernet In-Reply-To: <542140.85408.qm@web30802.mail.mud.yahoo.com> References: <542140.85408.qm@web30802.mail.mud.yahoo.com> Message-ID: <9639597a0809230959n2d253c77j793ab48303224230@mail.gmail.com> You may want to check out BFD for EIGRP, http://www.cisco.com/en/US/technologies/tk648/tk365/tk207/technologies_white_paper0900aecd80243fe7_ps6599_Products_White_Paper.html Regards, Kevin On Tue, Sep 23, 2008 at 11:25 AM, Philip Lavine wrote: > What is really bizarre is that I am down for minutes not seconds and the timers never fire. If I don't manually passive the connection eigrp will for some reason think there is a neighbor even though I am unable to source ping across the WAN. > > > > ----- Original Message ---- > From: Matthew Huff > To: Philip Lavine ; nanog > Sent: Tuesday, September 23, 2008 8:59:14 AM > Subject: RE: eigrp and managed ethernet > > Correct. Eigrp neighbor connectivity has a short-cut when L2 connectivity goes down, otherwise it will use the eigrp neighbor hold-down timer. You can decrease that timer: > > interface fa0/0 > ip hello-interval eigrp p x > ip hold-time eigrp p y > > where p is your eigrp as-number, and x is how often you want the hello (in seconds) and y is the max hold-down timer. Generally y is = x * 3 > > http://www.cisco.com/en/US/docs/ios/12_2/iproute/command/reference/1rfeigrp.html > > > ---- > Matthew Huff | One Manhattanville Rd > OTA Management LLC | Purchase, NY 10577 > www.ox.com | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-460-4139 > > -----Original Message----- > From: Philip Lavine [mailto:source_route at yahoo.com] > Sent: Tuesday, September 23, 2008 11:43 AM > To: nanog > Subject: eigrp and managed ethernet > > For some reason when I lose layer 3 connectivity between two managed Ethernet sites EIGRP does not bounce.Is this because the physical interface does not bounce? > > > > > From ge at linuxbox.org Tue Sep 23 12:03:05 2008 From: ge at linuxbox.org (Gadi Evron) Date: Tue, 23 Sep 2008 12:03:05 -0500 (CDT) Subject: Atrivo/Intercage In-Reply-To: <200809231439.m8NEdDqj091836@aurora.sol.net> References: <200809231439.m8NEdDqj091836@aurora.sol.net> Message-ID: http://www.giantitp.com/comics/oots0595.html I think that sums up this thread. On Tue, 23 Sep 2008, Joe Greco wrote: >> On Sep 22, 2008, at 4:33 PM, Tom Sparks (Applied Operations) wrote: >>> Intercage is not a big shop, there are very few people involved in >>> running it >> >> I have no dog in this fight, but I would comment on the "small shop" >> issue as it relates to handling abuse complaints. >> >> I own a small colo/hosting shop too. We don't have many employees. >> If we had to deal with so many abuse complaints that things were >> "getting lost in the noise", I'd have to seriously examine my AUP and >> associated enforcement policies, add staff to handle abuse issues, or >> both. Being small isn't an excuse. In fact, a small shop that runs a >> clean network should be far better at handling abuse issues than the >> larger players could ever hope to be. > > I would have to agree with this latter bit. We count incidents per YEAR. > On a hand. Mostly because we haven't made a habit of accepting random > clients, I guess, but were it a problem, it would be made not to be. > > Being proactive is a big part of this. For example, when ARIN began to > allow abuse contacts for IP space, we fairly quickly registered a POC > for 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 joe.doran at comcast.net Tue Sep 23 12:46:02 2008 From: joe.doran at comcast.net (Joseph Doran) Date: Tue, 23 Sep 2008 12:46:02 -0500 Subject: eigrp and managed ethernet Message-ID: <4fe778f0809231046l21cb354bnad9e9441b3cf9af4@mail.gmail.com> EIGRP timers over WAN media default to 60 seconds. Neighborship will not expire for up to 180 seconds. To verify your EIGRP neighborship do a "show ip eigrp neighbor" Message: 6 Date: Tue, 23 Sep 2008 09:25:34 -0700 (PDT) From: Philip Lavine Subject: Re: eigrp and managed ethernet To: nanog Message-ID: <542140.85408.qm at web30802.mail.mud.yahoo.com> Content-Type: text/plain; charset=us-ascii What is really bizarre is that I am down for minutes not seconds and the timers never fire. If I don't manually passive the connection eigrp will for some reason think there is a neighbor even though I am unable to source ping across the WAN. From ljb at merit.edu Tue Sep 23 13:05:26 2008 From: ljb at merit.edu (Larry Blunk) Date: Tue, 23 Sep 2008 14:05:26 -0400 Subject: prefix hijack by ASN 8997 In-Reply-To: <20080923085421.79007543@resin11.mta.everyone.net> References: <20080923085421.79007543@resin11.mta.everyone.net> Message-ID: <48D92FE6.4080106@merit.edu> Scott Weeks wrote: > ------ tme at multicasttech.com wrote: ---------- > From: Marshall Eubanks > > So, do you think this was lots of little tests / hijacks / mistakes ? > Or did it just not propagate very far ? > --------------------------------------------- > > According to Andree Toonk (and someone confirmed privately) ASN 8997 leaked a full table to ASN 3267 (who didn't filter!). The only upstream of ASN 3267 I saw in bgplay was ASN 174 (Cogent) who seems to have filtered, but I can't confirm. So I guess that the impact would've only been to the peers downstream of ASN 3267. > > scott > > > > > > --------------------------------------------- > Andree Toonk > > Not a false positive, It actually was detected by the RIS box in Moscow > (rrc13). Strange that it's not visible in RIS search website, but it's > definitely in the raw data files. > Looking at that raw data from both routeviews and Ripe, it looks like > they (AS8997) 'leaked' a full table, i.e. : > ---------------------------------------------- > > I did some analysis of updates on routeviews. The only routeviews peer I saw leaking the routes was AS3277 (out of 42 peers). There were roughly 117,000 prefixes with origin AS8997 with the path going through AS3267 to AS3277. The initial announcements were seen at 09:29:32 UTC and updates with the correct path were seen starting at about 09:36:42 UTC (last ones seen at 09:43:42). -Larry From kratzers at pa.net Tue Sep 23 14:25:37 2008 From: kratzers at pa.net (Stephen Kratzer) Date: Tue, 23 Sep 2008 15:25:37 -0400 Subject: eigrp and managed ethernet In-Reply-To: <4fe778f0809231046l21cb354bnad9e9441b3cf9af4@mail.gmail.com> References: <4fe778f0809231046l21cb354bnad9e9441b3cf9af4@mail.gmail.com> Message-ID: <200809231525.38211.kratzers@pa.net> On Tuesday 23 September 2008 13:46:02 Joseph Doran wrote: > EIGRP timers over WAN media default to 60 seconds. Neighborship will not > expire for up to 180 seconds. To verify your EIGRP neighborship do a "show > ip eigrp neighbor" > > > Message: 6 > Date: Tue, 23 Sep 2008 09:25:34 -0700 (PDT) > From: Philip Lavine > Subject: Re: eigrp and managed ethernet > To: nanog > Message-ID: <542140.85408.qm at web30802.mail.mud.yahoo.com> > Content-Type: text/plain; charset=us-ascii > > What is really bizarre is that I am down for minutes not seconds and the > timers never fire. If I don't manually passive the connection eigrp will > for some reason think there is a neighbor even though I am unable to source > ping across the WAN. With regard to EIGRP, link type is dictated by the medium and speed. In this case, Ethernet will be considered a high-speed, broadcast link regardless of its use for LAN or WAN, so the hello/dead intervals should, by default, be 5/15 seconds. From yahoo at jimpop.com Tue Sep 23 14:55:45 2008 From: yahoo at jimpop.com (Jim Popovitch) Date: Tue, 23 Sep 2008 15:55:45 -0400 Subject: prefix hijack by ASN 8997 In-Reply-To: <7ff145960809221913o1298820asf883adad7ce85628@mail.gmail.com> References: <20080922180658.7901E5DA@resin11.mta.everyone.net> <7ff145960809221913o1298820asf883adad7ce85628@mail.gmail.com> Message-ID: <7ff145960809231255w1fefd233m4a5378f4db41c4a@mail.gmail.com> On Mon, Sep 22, 2008 at 22:13, Jim Popovitch wrote: > On Mon, Sep 22, 2008 at 21:06, Scott Weeks wrote: >> >> I am hoping to confirm a short-duration prefix hijack of 72.234.0.0/15 (and another of our >> prefixes) by ASN 8997 ("OJSC North-West Telecom" in Russia) in using ASN 3267 >> (Russian Federal University Network) to advertise our space to ASN 3277 (Regional >> University and Scientific Network (RUSNet) of North-Western and Saint-Petersburg >> Area of Russia). > > Yep, saw this for 69.61.0.0/17 GlobalCompass (my upstream) this AM: > > SEQUENCE_NUMBER: 1222091638 > TYPE: last-hop > BGP-UPDATE-TIME: 1222075864 > PHAS-DETECT-TIME: 1222091637 > PHAS-NOTIFY-TIME: 1222091637 > PREFIX: 69.61.0.0/17 > SET: 3561,3267,3356,3491 > GAINED: 3267 <- Russian Federal University Network > LOST: > > SEQUENCE_NUMBER: 1222091638 > TYPE: origin > BGP-UPDATE-TIME: 1222075864 > PHAS-DETECT-TIME: 1222091637 > PHAS-NOTIFY-TIME: 1222091637 > PREFIX: 69.61.0.0/17 > SET: 8997,22653 > GAINED: 8997 <- OJSC North-West Telecom, St.-Petersburg, Russia > LOST: > > SEQUENCE_NUMBER: 1222096125 > TYPE: origin > BGP-UPDATE-TIME: 1222076569 > PHAS-DETECT-TIME: 1222092415 > PHAS-NOTIFY-TIME: 1222096124 > PREFIX: 69.61.0.0/17 > SET: 22653 <- GlobalCrossing Small typo on my part above... 22653 is GlobalCompass, not GlobalCrossing as I mistakenly typed above. -Jim P. From ccaputo at alt.net Tue Sep 23 17:13:23 2008 From: ccaputo at alt.net (Chris Caputo) Date: Tue, 23 Sep 2008 22:13:23 +0000 (UTC) Subject: Seattle Peering In-Reply-To: References: Message-ID: On Thu, 18 Sep 2008, Michael K. Smith wrote: > Hello Paul: > > On 9/18/08 8:01 AM, "Paul Stewart" wrote: > > Hi folks... > > > > We're working on some plans to peer in the Seattle area. Choices so far > > considered are SIX and PAIX Seattle pretty much.... > > > > I was of the impression that if you get a port on one of these > > exchanges, you can connect to the other one as well? Just looking for > > clarification from folks who are connected out there..;) Any charges to > > go between the exchanges or it just included? > > Speaking from the SIX side, there is no charge to connect to the fabric if > you supply the optics, and there is a one-time fiber cross connect charge of > $200.00 US. The SIX and PAIX are directly connected and you can peer across > the fabric. The SIX page is http://www.seattleix.net for more info or you > can email me directly. And keep in mind that while the SIX and PAIX-SEA are directly connected, the exchanges are on different VLANs from the perspective of a PAIX-SEA connection. If you connect on the SIX side, you can only reach the SIX fabric. No MRC. If you connect on the PAIX-SEA side, you can reach both the SIX fabric and the PAIX-SEA fabric via a single router port. For MRC talk to an S&D rep. Chris From pstewart at nexicomgroup.net Tue Sep 23 18:25:26 2008 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Tue, 23 Sep 2008 19:25:26 -0400 Subject: Seattle Peering In-Reply-To: References: Message-ID: <89D27DE3375BB6428DDCC2927489826A019E3022@nexus.nexicomgroup.net> Thanks very much... we have a price from S&D for the x-connect. If we connect on the PAIX side (most likely) do we need multiple VLAN's? I had planned on a single VLAN on the port for there - just need to understand ;) Thanks, Paul -----Original Message----- From: Chris Caputo [mailto:ccaputo at alt.net] Sent: September 23, 2008 6:13 PM To: Paul Stewart; Michael K. Smith Cc: NANOG list Subject: Re: Seattle Peering On Thu, 18 Sep 2008, Michael K. Smith wrote: > Hello Paul: > > On 9/18/08 8:01 AM, "Paul Stewart" wrote: > > Hi folks... > > > > We're working on some plans to peer in the Seattle area. Choices so far > > considered are SIX and PAIX Seattle pretty much.... > > > > I was of the impression that if you get a port on one of these > > exchanges, you can connect to the other one as well? Just looking for > > clarification from folks who are connected out there..;) Any charges to > > go between the exchanges or it just included? > > Speaking from the SIX side, there is no charge to connect to the fabric if > you supply the optics, and there is a one-time fiber cross connect charge of > $200.00 US. The SIX and PAIX are directly connected and you can peer across > the fabric. The SIX page is http://www.seattleix.net for more info or you > can email me directly. And keep in mind that while the SIX and PAIX-SEA are directly connected, the exchanges are on different VLANs from the perspective of a PAIX-SEA connection. If you connect on the SIX side, you can only reach the SIX fabric. No MRC. If you connect on the PAIX-SEA side, you can reach both the SIX fabric and the PAIX-SEA fabric via a single router port. For MRC talk to an S&D rep. Chris ---------------------------------------------------------------------------- "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 ccaputo at alt.net Tue Sep 23 18:41:55 2008 From: ccaputo at alt.net (Chris Caputo) Date: Tue, 23 Sep 2008 23:41:55 +0000 (UTC) Subject: Seattle Peering In-Reply-To: <89D27DE3375BB6428DDCC2927489826A019E3022@nexus.nexicomgroup.net> References: <89D27DE3375BB6428DDCC2927489826A019E3022@nexus.nexicomgroup.net> Message-ID: If you are in S&D/PAIX's facility, you have two options for connecting to the SIX: - direct to the SIX core via the fiber-meet-me-room, thus no VLAN. You won't get access to the PAIX-SEA fabric with this method, but if what you really want is the SIX, this is the way to go. - direct to the PAIX-SEA switch, in which case you'll need to instruct S&D to enable your port to also have access to the SIX fabric. Your router will have two VLAN interfaces on the port, one for PAIX-SEA and one for the SIX. Feel free to direct further questions to info at seattleix.net if you like. Chris On Tue, 23 Sep 2008, Paul Stewart wrote: > Thanks very much... we have a price from S&D for the x-connect. If we > connect on the PAIX side (most likely) do we need multiple VLAN's? I > had planned on a single VLAN on the port for there - just need to > understand ;) > > Thanks, > > Paul > > > -----Original Message----- > From: Chris Caputo [mailto:ccaputo at alt.net] > Sent: September 23, 2008 6:13 PM > To: Paul Stewart; Michael K. Smith > Cc: NANOG list > Subject: Re: Seattle Peering > > On Thu, 18 Sep 2008, Michael K. Smith wrote: > > Hello Paul: > > > > On 9/18/08 8:01 AM, "Paul Stewart" wrote: > > > Hi folks... > > > > > > We're working on some plans to peer in the Seattle area. Choices so > > > far considered are SIX and PAIX Seattle pretty much.... > > > > > > I was of the impression that if you get a port on one of these > > > exchanges, you can connect to the other one as well? Just looking > > > for clarification from folks who are connected out there..;) Any > > > charges to go between the exchanges or it just included? > > > > Speaking from the SIX side, there is no charge to connect to the > > fabric if you supply the optics, and there is a one-time fiber cross > > connect charge of $200.00 US. The SIX and PAIX are directly connected > > and you can peer across the fabric. The SIX page is > > http://www.seattleix.net for more info or you can email me directly. > > And keep in mind that while the SIX and PAIX-SEA are directly connected, > > the exchanges are on different VLANs from the perspective of a PAIX-SEA > connection. > > If you connect on the SIX side, you can only reach the SIX fabric. No > MRC. > > If you connect on the PAIX-SEA side, you can reach both the SIX fabric > and the PAIX-SEA fabric via a single router port. For MRC talk to an > S&D rep. > > Chris From pauldotwall at gmail.com Tue Sep 23 19:46:58 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Tue, 23 Sep 2008 20:46:58 -0400 Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <1bbf3c240809221627wa9e6879h82a81aa8b433ec92@mail.gmail.com> References: <1bbf3c240809221627wa9e6879h82a81aa8b433ec92@mail.gmail.com> Message-ID: <620fd17c0809231746r718e354fofc0d58b8c97f96a1@mail.gmail.com> Hold the rejoicing, Atrivo is back, this time on UnitedLayer. I'd contact them, only they seem to change CTOs every month or two, does anybody know who's currently in charge? Thank you, and Drive Slow, Paul Wall From fergdawgster at gmail.com Tue Sep 23 19:55:27 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Tue, 23 Sep 2008 17:55:27 -0700 Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <620fd17c0809231746r718e354fofc0d58b8c97f96a1@mail.gmail.com> References: <1bbf3c240809221627wa9e6879h82a81aa8b433ec92@mail.gmail.com> <620fd17c0809231746r718e354fofc0d58b8c97f96a1@mail.gmail.com> Message-ID: <6cd462c00809231755r464201d0xec1f56d22b7db5ae@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Well, their management team is listed here: http://www.unitedlayer.com/team.html - - ferg On Tue, Sep 23, 2008 at 5:46 PM, Paul Wall wrote: > Hold the rejoicing, Atrivo is back, this time on UnitedLayer. > > I'd contact them, only they seem to change CTOs every month or two, > does anybody know who's currently in charge? > > Thank you, and Drive Slow, > Paul Wall > > -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI2Y/zq1pz9mNUZTMRAnfWAKClED9vjhHusr2Y6+HJ4Bc9fHAosACeOhfK 8coixrmTH5I3Hlh2phmut5w= =gzBi -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From jrhett at netconsonance.com Tue Sep 23 21:58:53 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 23 Sep 2008 19:58:53 -0700 Subject: Atrivo/Intercage In-Reply-To: <20080922203331.GA57011@web1.wotanworks.net> References: <20080922203331.GA57011@web1.wotanworks.net> Message-ID: <3C4CCAD6-44AB-441F-9B93-B0520463233C@netconsonance.com> On Sep 22, 2008, at 1:33 PM, Tom Sparks (Applied Operations) wrote: > I also don't believe Intercage was complicit in any > net-crime; Thats not to say it didn't exist, but more along the lines > of they got lost in the noise of running a business. Which is not acceptable. You answer your abuse complaints, you shut down your spammers. Period, end of subject. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From russm2k8 at yahoo.com Tue Sep 23 22:07:35 2008 From: russm2k8 at yahoo.com (Russell Mitchell) Date: Tue, 23 Sep 2008 20:07:35 -0700 (PDT) Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer Message-ID: <309636.9145.qm@web45004.mail.sp1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-593512929-1222225655=:9145" --0-593512929-1222225655=:9145 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hello All,=0A=A0=0AIt seems you all missed the memo.=0AAs of about 11PM PST= Last night 09/22/08, Esthost has been ENTIRELY Shutdown. They no longer ha= ve ANY Machine on my network.=0A=A0=0AI'm currently starting to monitor som= e of the public media, such as google, DroneBL, as well as several Anti-Mal= ware community websites for abuse.=0A=A0=0ABeing that Esthost is now entire= ly GONE, we should not have any further issues.=0AIn the case that somethin= g=A0does arise, such as an exploited host, we're currently developing a gam= e plan for=A0response to=A0the issues.=0ATo make the best effort towards co= mbatting=A0abuse on our network, here's what I have planned so far for ANY = Type of abuse:=0AStep 1,=A0Suspend Power to the affected machine.=0AStep 2,= Call/Email the client whom the affected machine is leased to.=0AStep 3, Al= low the client=A0the option to=A0investigate the machine further (Nullroute= access via KVM)=0AStep=A04, Verify the=A0reported content, domain, user, o= r exploit=A0is patched/eliminated from the machine.=0AStep 5,=A0Remove the = Nullroute. Allow the machine to return to the network.=0A=A0=0AAny comments= ? =0A=A0=0AThis is=A0the result of a zero tolerance policy regarding abuse.= If it's clear that the server owner is the cause of the abusive material e= tc, the client will then be immediately cancelled. No questions.=A0=0A=0A= =0AIt seems that this approach will be the best supported by the anti-abuse= communities, so please let me know your input.=0A=0AThank you for your tim= e. Have a great day.=0A=A0---=0ARussell Mitchell=0A=0AInterCage, Inc.=0A=0A= =0A=0A----- Original Message ----=0AFrom: Paul Wall = =0ATo: Mark Foo =0ACc: nanog at nanog.org=0ASent: Tues= day, September 23, 2008 5:46:58 PM=0ASubject: Re: YAY! Re: Atrivo/Intercage= : NO Upstream depeer=0A=0AHold the rejoicing, Atrivo is back, this time on = UnitedLayer.=0A=0AI'd contact them, only they seem to change CTOs every mon= th or two,=0Adoes anybody know who's currently in charge?=0A=0AThank you, a= nd Drive Slow,=0APaul Wall=0A=0A=0A --0-593512929-1222225655=:9145 Content-Type: text/html; charset=us-ascii

Hello All,

 

It seems you all missed the memo.
As of about 11PM PST Last night 09/22/08, Esthost has been ENTIRELY Shutdown. They no longer have ANY Machine on my network.

 

I'm currently starting to monitor some of the public media, such as google, DroneBL, as well as several Anti-Malware community websites for abuse.

 

Being that Esthost is now entirely GONE, we should not have any further issues.

In the case that something does arise, such as an exploited host, we're currently developing a game plan for response to the issues.

To make the best effort towards combatting abuse on our network, here's what I have planned so far for ANY Type of abuse:

Step 1, Suspend Power to the affected machine.

Step 2, Call/Email the client whom the affected machine is leased to.

Step 3, Allow the client the option to investigate the machine further (Nullroute access via KVM)

Step 4, Verify the reported content, domain, user, or exploit is patched/eliminated from the machine.

Step 5, Remove the Nullroute. Allow the machine to return to the network.

 

Any comments?

 

This is the result of a zero tolerance policy regarding abuse. If it's clear that the server owner is the cause of the abusive material etc, the client will then be immediately cancelled. No questions. 

 
It seems that this approach will be the best supported by the anti-abuse communities, so please let me know your input.
 
Thank you for your time. Have a great day.
 
---
Russell Mitchell
InterCage, Inc.

----- Original Message ----
From: Paul Wall <pauldotwall at gmail.com>
To: Mark Foo <mark.foo.dog at gmail.com>
Cc: nanog at nanog.org
Sent: Tuesday, September 23, 2008 5:46:58 PM
Subject: Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer

Hold the rejoicing, Atrivo is back, this time on UnitedLayer.

I'd contact them, only they seem to change CTOs every month or two,
does anybody know who's currently in charge?

Thank you, and Drive Slow,
Paul Wall


--0-593512929-1222225655=:9145-- From jgreco at ns.sol.net Tue Sep 23 22:12:43 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 23 Sep 2008 22:12:43 -0500 (CDT) Subject: Atrivo/Intercage In-Reply-To: <3C4CCAD6-44AB-441F-9B93-B0520463233C@netconsonance.com> from "Jo Rhett" at Sep 23, 2008 07:58:53 PM Message-ID: <200809240312.m8O3Chin019488@aurora.sol.net> > On Sep 22, 2008, at 1:33 PM, Tom Sparks (Applied Operations) wrote: > > I also don't believe Intercage was complicit in any > > net-crime; Thats not to say it didn't exist, but more along the lines > > of they got lost in the noise of running a business. > > Which is not acceptable. You answer your abuse complaints, you shut > down your spammers. Period, end of subject. That's a bit '90's. I'll settle for s/answer/handle/, because I don't think that most sites are willing to actually discuss abuse issues with random folks submitting complaints, and so that leaves you with either sending a form letter of some sort, or not saying anything. Further, many places seem to send form letters but not do anything. I am not sure that there is much (or any) value-add in sending a response, unless further information is needed. >From my point of view, the best response is when the problem simply goes away. A personal reply (rather than a form letter) is also generally a really good sign that someone cares enough to show that they're doing something, but again that seems to be the exception rather than the norm. The Afterburner experience, however, should be an excellent example for the difference that simply *showing* you care and are doing something makes. ... 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 jgreco at ns.sol.net Tue Sep 23 22:20:18 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 23 Sep 2008 22:20:18 -0500 (CDT) Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <309636.9145.qm@web45004.mail.sp1.yahoo.com> from "Russell Mitchell" at Sep 23, 2008 08:07:35 PM Message-ID: <200809240320.m8O3KIw0019735@aurora.sol.net> > Hello All,=0A=A0=0AIt seems you all missed the memo.=0AAs of about 11PM PST= > Last night 09/22/08, Esthost has been ENTIRELY Shutdown. They no longer ha= > ve ANY Machine on my network.=0A=A0=0AI'm currently starting to monitor som= > e of the public media, such as google, DroneBL, as well as several Anti-Mal= > ware community websites for abuse.=0A=A0=0ABeing that Esthost is now entire= > ly GONE, we should not have any further issues.=0AIn the case that somethin= > g=A0does arise, such as an exploited host, we're currently developing a gam= > e plan for=A0response to=A0the issues.=0ATo make the best effort towards co= > mbatting=A0abuse on our network, here's what I have planned so far for ANY = > Type of abuse:=0AStep 1,=A0Suspend Power to the affected machine.=0AStep 2,= > Call/Email the client whom the affected machine is leased to.=0AStep 3, Al= > low the client=A0the option to=A0investigate the machine further (Nullroute= > access via KVM)=0AStep=A04, Verify the=A0reported content, domain, user, o= > r exploit=A0is patched/eliminated from the machine.=0AStep 5,=A0Remove the = > Nullroute. Allow the machine to return to the network.=0A=A0=0AAny comments= > ? =0A=A0=0AThis is=A0the result of a zero tolerance policy regarding abuse.= > If it's clear that the server owner is the cause of the abusive material e= > tc, the client will then be immediately cancelled. No questions.=A0=0A=0A= > =0AIt seems that this approach will be the best supported by the anti-abuse= > communities, so please let me know your input.=0A=0AThank you for your tim= > e. Have a great day.=0A=A0---=0ARussell Mitchell=0A=0AInterCage, Inc.=0A=0A= > =0A=0A----- Original Message ----=0AFrom: Paul Wall = > =0ATo: Mark Foo =0ACc: nanog at nanog.org=0ASent: Tues= > day, September 23, 2008 5:46:58 PM=0ASubject: Re: YAY! Re: Atrivo/Intercage= > : NO Upstream depeer=0A=0AHold the rejoicing, Atrivo is back, this time on = > UnitedLayer.=0A=0AI'd contact them, only they seem to change CTOs every mon= > th or two,=0Adoes anybody know who's currently in charge?=0A=0AThank you, a= > nd Drive Slow,=0APaul Wall=0A=0A=0A Speaking of missing memos... mailing lists are not highly compatible with HTML or some clients that like to encode list mail. The above is what your mail looked like to some people. I would suggest a different Step 1. Instead of killing power, simply isolate the affected machine. This might be as simple as putting up a firewall rule or two, if it is simply sending outgoing SMTP spam, or for more complex issues, downing the port facing the machine in question. Killing the power may destroy useful forensic clues about what happened to the system, and may damage the system. ... 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 christopher.morrow at gmail.com Tue Sep 23 22:21:03 2008 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Tue, 23 Sep 2008 23:21:03 -0400 Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <309636.9145.qm@web45004.mail.sp1.yahoo.com> References: <309636.9145.qm@web45004.mail.sp1.yahoo.com> Message-ID: <75cb24520809232021x1e5e93d8m9462b0e939aac8a@mail.gmail.com> please to not email in html format... yikes! Russ, could you re-mail whatever content you just sent, in plain text? On Tue, Sep 23, 2008 at 11:07 PM, Russell Mitchell wrote: > MIME-Version: 1.0 > Content-Type: multipart/alternative; boundary="0-593512929-1222225655=:9145" > > --0-593512929-1222225655=:9145 > Content-Type: text/plain; charset=iso-8859-1 > Content-Transfer-Encoding: quoted-printable > > Hello All,=0A=A0=0AIt seems you all missed the memo.=0AAs of about 11PM PST= > Last night 09/22/08, Esthost has been ENTIRELY Shutdown. They no longer ha= > ve ANY Machine on my network.=0A=A0=0AI'm currently starting to monitor som= > e of the public media, such as google, DroneBL, as well as several Anti-Mal= > ware community websites for abuse.=0A=A0=0ABeing that Esthost is now entire= > ly GONE, we should not have any further issues.=0AIn the case that somethin= > g=A0does arise, such as an exploited host, we're currently developing a gam= > e plan for=A0response to=A0the issues.=0ATo make the best effort towards co= > mbatting=A0abuse on our network, here's what I have planned so far for ANY = > Type of abuse:=0AStep 1,=A0Suspend Power to the affected machine.=0AStep 2,= > Call/Email the client whom the affected machine is leased to.=0AStep 3, Al= > low the client=A0the option to=A0investigate the machine further (Nullroute= > access via KVM)=0AStep=A04, Verify the=A0reported content, domain, user, o= > r exploit=A0is patched/eliminated from the machine.=0AStep 5,=A0Remove the = > Nullroute. Allow the machine to return to the network.=0A=A0=0AAny comments= > ? =0A=A0=0AThis is=A0the result of a zero tolerance policy regarding abuse.= > If it's clear that the server owner is the cause of the abusive material e= > tc, the client will then be immediately cancelled. No questions.=A0=0A=0A= > =0AIt seems that this approach will be the best supported by the anti-abuse= > communities, so please let me know your input.=0A=0AThank you for your tim= > e. Have a great day.=0A=A0---=0ARussell Mitchell=0A=0AInterCage, Inc.=0A=0A= > =0A=0A----- Original Message ----=0AFrom: Paul Wall = > =0ATo: Mark Foo =0ACc: nanog at nanog.org=0ASent: Tues= > day, September 23, 2008 5:46:58 PM=0ASubject: Re: YAY! Re: Atrivo/Intercage= > : NO Upstream depeer=0A=0AHold the rejoicing, Atrivo is back, this time on = > UnitedLayer.=0A=0AI'd contact them, only they seem to change CTOs every mon= > th or two,=0Adoes anybody know who's currently in charge?=0A=0AThank you, a= > nd Drive Slow,=0APaul Wall=0A=0A=0A > --0-593512929-1222225655=:9145 > Content-Type: text/html; charset=us-ascii > >

Hello All,

>

>

It seems you all missed the memo.
As of about 11PM PST Last night 09/22/08, Esthost has been ENTIRELY Shutdown. They no longer have ANY Machine on my network.

>

>

I'm currently starting to monitor some of the public media, such as google, DroneBL, as well as several Anti-Malware community websites for abuse.

>

>

Being that Esthost is now entirely GONE, we should not have any further issues.

>

In the case that something does arise, such as an exploited host, we're currently developing a game plan for response to the issues.

>

To make the best effort towards combatting abuse on our network, here's what I have planned so far for ANY Type of abuse:

>

Step 1, Suspend Power to the affected machine.

>

Step 2, Call/Email the client whom the affected machine is leased to.

>

Step 3, Allow the client the option to investigate the machine further (Nullroute access via KVM)

>

Step 4, Verify the reported content, domain, user, or exploit is patched/eliminated from the machine.

>

Step 5, Remove the Nullroute. Allow the machine to return to the network.

>

>

Any comments?

>

>

This is the result of a zero tolerance policy regarding abuse. If it's clear that the server owner is the cause of the abusive material etc, the client will then be immediately cancelled. No questions.

>
>
>
>
It seems that this approach will be the best supported by the anti-abuse communities, so please let me know your input.
>
>
Thank you for your time. Have a great day.
---
Russell Mitchell
>
InterCage, Inc.
>

>
----- Original Message ----
From: Paul Wall
To: Mark Foo
Cc: nanog at nanog.org
Sent: Tuesday, September 23, 2008 5:46:58 PM
Subject: Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer

Hold the rejoicing, Atrivo is back, this time on UnitedLayer.

I'd contact them, only they seem to change CTOs every month or two,
does anybody know who's currently in charge?

Thank you, and Drive Slow,
Paul Wall


> > > --0-593512929-1222225655=:9145-- > > > From christopher.morrow at gmail.com Tue Sep 23 22:23:48 2008 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Tue, 23 Sep 2008 23:23:48 -0400 Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <200809240320.m8O3KIw0019735@aurora.sol.net> References: <309636.9145.qm@web45004.mail.sp1.yahoo.com> <200809240320.m8O3KIw0019735@aurora.sol.net> Message-ID: <75cb24520809232023r6bb5820eubed1524b13acddc1@mail.gmail.com> On Tue, Sep 23, 2008 at 11:20 PM, Joe Greco wrote: > I would suggest a different Step 1. Instead of killing power, simply > isolate the affected machine. This might be as simple as putting up a > firewall rule or two, if it is simply sending outgoing SMTP spam, or it's probably easiest (depending on the network gear of course) to just put the lan port into an isolated VLAN. It's not the 100% solution (some badness rm's itself once it loses connectivity to the internets) but it'd make things simpler for the client/LEA when they need to figure out what happened. -chris From frnkblk at iname.com Tue Sep 23 22:43:55 2008 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 23 Sep 2008 22:43:55 -0500 Subject: hat tip to .gov hostmasters In-Reply-To: <869CC897-C081-4357-A27E-8412F7DC99BE@hubris.net> References: <4EBDBF94-62BD-48E9-A262-A4E9E91249E4@gmail.com> <924f29280809220752i646b69e5u5455ac5426f0cc07@mail.gmail.com> <20080922165937.62377b74@mlejnas.priv.castalie.org> <869CC897-C081-4357-A27E-8412F7DC99BE@hubris.net> Message-ID: Pretty soon we'll have a blacklist of DNS servers that don't support DNSSEC for .gov. =) Frank -----Original Message----- From: Chris Owen [mailto:owenc at hubris.net] Sent: Monday, September 22, 2008 10:02 AM To: NANOG list Subject: Re: hat tip to .gov hostmasters -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sep 22, 2008, at 9:59 AM, Simon Vallet wrote: > On Mon, 22 Sep 2008 10:52:42 -0400 > "Jason Frisvold" wrote: > >> I'm not much up on DNSSEC, but don't you need to be using a resolver >> that recognizes DNSSEC in order for this to be useful? > > You do -- and last time I checked few native resolvers actually did : > glibc doesn't, and I'd be surprised if the Windows resolver does Chicken, meet egg. I think the point of the original post is that one end or the other has to start things. At least we have one US zone doing something on the server end of things. 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 iEYEARECAAYFAkjXs30ACgkQElUlCLUT2d0SfwCbB8FQ4izN061GoQQMl3fkq+NT ga0AoJnwGG8PfBs5PaziRB6m0NQBuZwc =68dm -----END PGP SIGNATURE----- From williams.bruce at gmail.com Tue Sep 23 22:47:41 2008 From: williams.bruce at gmail.com (Bruce Williams) Date: Tue, 23 Sep 2008 20:47:41 -0700 Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <75cb24520809232023r6bb5820eubed1524b13acddc1@mail.gmail.com> References: <309636.9145.qm@web45004.mail.sp1.yahoo.com> <200809240320.m8O3KIw0019735@aurora.sol.net> <75cb24520809232023r6bb5820eubed1524b13acddc1@mail.gmail.com> Message-ID: <775e001a0809232047u8c8b69eq238152b7354f803@mail.gmail.com> using bolt cutters on cables has a certain satisfaction... On Tue, Sep 23, 2008 at 8:23 PM, Christopher Morrow wrote: > On Tue, Sep 23, 2008 at 11:20 PM, Joe Greco wrote: > >> I would suggest a different Step 1. Instead of killing power, simply >> isolate the affected machine. This might be as simple as putting up a >> firewall rule or two, if it is simply sending outgoing SMTP spam, or > > it's probably easiest (depending on the network gear of course) to > just put the lan port into an isolated VLAN. It's not the 100% > solution (some badness rm's itself once it loses connectivity to the > internets) but it'd make things simpler for the client/LEA when they > need to figure out what happened. > > -chris > > From russm2k8 at yahoo.com Tue Sep 23 23:05:53 2008 From: russm2k8 at yahoo.com (Russell Mitchell) Date: Tue, 23 Sep 2008 21:05:53 -0700 (PDT) Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer Message-ID: <121828.37272.qm@web45007.mail.sp1.yahoo.com> Apologies, Yahoo was set to "Rich Text" :( ----- Hello All, It seems you all missed the memo.As of about 11PM PST Last night 09/22/08, Esthost has been ENTIRELY Shutdown. They no longer have ANY Machine on my network. I'm currently starting to monitor some of the public media, such as google, DroneBL, as well as several Anti-Malware community websites for abuse. Being that Esthost is now entirely GONE, we should not have any further issues. In the case that something does arise, such as an exploited host, we're currently developing a game plan for response to the issues. To make the best effort towards combatting abuse on our network, here's what I have planned so far for ANY Type of abuse: Step 1, Suspend Power to the affected machine. Step 2, Call/Email the client whom the affected machine is leased to. Step 3, Allow the client the option to investigate the machine further (Nullroute access via KVM)= Step 4, Verify the reported content, domain, user, or exploit is patched/eliminated from the machine. Step 5, Remove the Nullroute. Allow the machine to return to the network. Any comments? This is the result of a zero tolerance policy regarding abuse. If it's clear that the server owner is the cause of the abusive material etc, the client will then be immediately cancelled. No questions. It seems that this approach will be the best supported by the anti-abuse communities, so please let me know your input. Thank you for your time. Have a great day. --- Russell Mitchell InterCage, Inc. From fergdawgster at gmail.com Tue Sep 23 23:22:03 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Tue, 23 Sep 2008 21:22:03 -0700 Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <121828.37272.qm@web45007.mail.sp1.yahoo.com> References: <121828.37272.qm@web45007.mail.sp1.yahoo.com> Message-ID: <6cd462c00809232122p7aa506fav1a0900bbbcc746e0@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Russ, While I think that is great and everything, can you explain why Cernel is now originating prefixes which were originally originated by Atrivo/Intercage? I'd be curious as to your explanation. Thanks, - - ferg On Tue, Sep 23, 2008 at 9:05 PM, Russell Mitchell wrote: > Apologies, Yahoo was set to "Rich Text" :( > > ----- > > Hello All, > > It seems you all missed the memo.As of about 11PM PST > Last night 09/22/08, Esthost has been ENTIRELY Shutdown. > They no longer have ANY Machine on my network. > > I'm currently starting to monitor some of the public media, such as > google, DroneBL, as well as several Anti-Malware community websites for > abuse. Being that Esthost is now entirely GONE, we should not have any > further issues. In the case that something does arise, such as an > exploited host, we're currently developing a game plan for response to > the issues. > > To make the best effort towards combatting abuse on our network, here's > what I have planned so far for ANY Type of abuse: Step 1, Suspend Power > to the affected machine. > Step 2, Call/Email the client whom the affected machine is leased to. > Step 3, Allow the client the option to investigate the machine further > (Nullroute access via KVM)= Step 4, Verify the reported content, domain, > user, or exploit is patched/eliminated from the machine. Step 5, Remove > the Nullroute. Allow the machine to return to the network. > > Any comments? This is the result of a zero tolerance policy regarding > abuse. > > If it's clear that the server owner is the cause of the abusive material > etc, the client will then be immediately cancelled. No questions. It > seems that this approach will be the best supported by the anti-abuse > communities, so please let me know your input. > > Thank you for your time. Have a great day. > > --- > Russell Mitchell > InterCage, Inc. > > > > > > -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI2cBUq1pz9mNUZTMRAtbAAJwKk/H/9Pz4YelIgnYvtuCCDhmuswCfcrfV PTUD/SyPo8+zHpACucRPqk4= =+rwg -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From fergdawgster at gmail.com Tue Sep 23 23:42:53 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Tue, 23 Sep 2008 21:42:53 -0700 Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <121828.37272.qm@web45007.mail.sp1.yahoo.com> References: <121828.37272.qm@web45007.mail.sp1.yahoo.com> Message-ID: <6cd462c00809232142x23c244fdk33cf05523d0210f1@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It may be true that Estdomains has moved a couple of the external-facing a hosting hosts into the a Netherlands hosting provider in conjunction with this whole situation -- folks are watching very carefully. estdomains.com A 94.102.49.3 storefront.estdomains.com A 94.102.49.5 www.estdomains.com A 94.102.49.4 www.estsecure.com A 94.102.49.5 AS | IP | AS Name 29073 | 94.102.49.3 | ECATEL-AS AS29073, Ecatel Network % Information related to '94.102.48.0 - 94.102.63.255' inetnum: 94.102.48.0 - 94.102.63.255 netname: NL-ECATEL-20080829 descr: Ecatel LTD country: NL org: ORG-EL38-RIPE admin-c: RvE16-RIPE tech-c: RvE16-RIPE status: ALLOCATED PA mnt-by: RIPE-NCC-HM-MNT mnt-lower: ECATEL-MNT mnt-routes: ECATEL-MNT source: RIPE # Filtered organisation: ORG-EL38-RIPE org-name: Ecatel LTD org-type: LIR address: Ecatel LTD Reinier van Eeden P.O.Box 19533 2521 CA The Hague NETHERLANDS phone: +31702204015 fax-no: +31702204015 e-mail: r.eeden at ecatel.net admin-c: RvE16-RIPE mnt-ref: ECATEL-MNT mnt-ref: RIPE-NCC-HM-MNT mnt-by: RIPE-NCC-HM-MNT source: RIPE # Filtered DNSLogger: estdomains.com A 94.102.49.3 estdomains.com A 216.255.176.238 estdomains.com NS ans1.esthost.com estdomains.com NS ans2.esthost.com estdomains.com NS temp1.estdomains.com estdomains.com NS ns1.estdomains.com estdomains.com NS temp2.estdomains.com estdomains.com NS ns2.estdomains.com http://www.bfk.de/bfk_dnslogger.html Thanks, - - ferg On Tue, Sep 23, 2008 at 9:05 PM, Russell Mitchell wrote: > Apologies, Yahoo was set to "Rich Text" :( > > ----- > > Hello All, > > It seems you all missed the memo.As of about 11PM PST > Last night 09/22/08, Esthost has been ENTIRELY Shutdown. > They no longer have ANY Machine on my network. > -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI2cVCq1pz9mNUZTMRAtC1AJ9UK326w0H3C8lpB1cxz6EJC6KbqwCgjlwA 3WvkkgfWuVapwt1OKbys4dk= =B4vI -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From marka at isc.org Tue Sep 23 23:59:48 2008 From: marka at isc.org (Mark Andrews) Date: Wed, 24 Sep 2008 14:59:48 +1000 (EST) Subject: Yahoo Email In-Reply-To: <200809240320.m8O3KIw0019735@aurora.sol.net> References: <309636.9145.qm@web45004.mail.sp1.yahoo.com> Message-ID: <200809240459.m8O4xmbR002833@drugs.dv.isc.org> In article <200809240320.m8O3KIw0019735 at aurora.sol.net> you write: >> Hello All,=0A=A0=0AIt seems you all missed the memo.=0AAs of about 11PM PST= >> Last night 09/22/08, Esthost has been ENTIRELY Shutdown. They no longer ha= >> ve ANY Machine on my network.=0A=A0=0AI'm currently starting to monitor som= >> e of the public media, such as google, DroneBL, as well as several Anti-Mal= >> ware community websites for abuse.=0A=A0=0ABeing that Esthost is now entire= [snipped] >Speaking of missing memos... mailing lists are not highly compatible >with HTML or some clients that like to encode list mail. The above is >what your mail looked like to some people. Most email from Yahoo is like this. Yahoo doesn't know how to do quoted-printable properly. It displays ok if you speak mime but not if you don't. The intent of quoted-printable is to display ASCII nicely if you don't have a mime compliant reader. Mark RFC 2045. The Quoted-Printable encoding is intended to represent data that largely consists of octets that correspond to printable characters in the US-ASCII character set. It encodes the data in such a way that the resulting octets are unlikely to be modified by mail transport. If the data being encoded are mostly US-ASCII text, the encoded form of the data remains largely recognizable by humans. A body which is entirely US-ASCII may also be encoded in Quoted-Printable to ensure the integrity of the data should the message pass through a character-translating, and/or line-wrapping gateway. also (4) (Line Breaks) A line break in a text body, represented as a CRLF sequence in the text canonical form, must be represented by a (RFC 822) line break, which is also a CRLF sequence, in the Quoted-Printable encoding. Since the canonical representation of media types other than text do not generally include the representation of line breaks as CRLF sequences, no hard line breaks (i.e. line breaks that are intended to be meaningful and to be displayed to the user) can occur in the quoted-printable encoding of such types. Sequences like "=0D", "=0A", "=0A=0D" and "=0D=0A" will routinely appear in non-text data represented in quoted- printable, of course. From russm2k8 at yahoo.com Wed Sep 24 00:13:53 2008 From: russm2k8 at yahoo.com (Russell Mitchell) Date: Tue, 23 Sep 2008 22:13:53 -0700 (PDT) Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer Message-ID: <548200.23333.qm@web45014.mail.sp1.yahoo.com> Hello Paul, Those are their IP Blocks. We were simply routing them, as they were our client. They've owned these blocks for quite a while. They seem to have moved that after a day of being down. I haven't been monitoring their blocks, and made the decision Sunday Night that they were no longer going to be allowed on our network. I believe the blocks your referring to are their 85.255 Blocks? Registered to "InHoster". I believe those?prefixes are an entity of their's, though I don't know for sure. Perhaps ask them? Cernel is their own ASN. It's not associated with our company. Thank you for your time. Have a great day.? --- Russell Mitchell InterCage, Inc. ----- Original Message ---- From: Paul Ferguson To: Russell Mitchell Cc: nanog at nanog.org Sent: Tuesday, September 23, 2008 9:22:03 PM Subject: Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Russ, While I think that is great and everything, can you explain why Cernel is now originating prefixes which were originally originated by Atrivo/Intercage? I'd be curious as to your explanation. Thanks, - - ferg On Tue, Sep 23, 2008 at 9:05 PM, Russell Mitchell wrote: > Apologies, Yahoo was set to "Rich Text" :( > > ----- > > Hello All, > > It seems you all missed the memo.As of about 11PM PST > Last night 09/22/08, Esthost has been ENTIRELY Shutdown. > They no longer have ANY Machine on my network. > > I'm currently starting to monitor some of the public media, such as > google, DroneBL, as well as several Anti-Malware community websites for > abuse. Being that Esthost is now entirely GONE, we should not have any > further issues. In the case that something does arise, such as an > exploited host, we're currently developing a game plan for response to > the issues. > > To make the best effort towards combatting abuse on our network, here's > what I have planned so far for ANY Type of abuse: Step 1, Suspend Power > to the affected machine. > Step 2, Call/Email the client whom the affected machine is leased to. > Step 3, Allow the client the option to investigate the machine further > (Nullroute access via KVM)= Step 4, Verify the reported content, domain, > user, or exploit is patched/eliminated from the machine. Step 5, Remove > the Nullroute. Allow the machine to return to the network. > > Any comments? This is the result of a zero tolerance policy regarding > abuse. > > If it's clear that the server owner is the cause of the abusive material > etc, the client will then be immediately cancelled. No questions. It > seems that this approach will be the best supported by the anti-abuse > communities, so please let me know your input. > > Thank you for your time. Have a great day. > > --- > Russell Mitchell > InterCage, Inc. > > > > > > -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI2cBUq1pz9mNUZTMRAtbAAJwKk/H/9Pz4YelIgnYvtuCCDhmuswCfcrfV PTUD/SyPo8+zHpACucRPqk4= =+rwg -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From russm2k8 at yahoo.com Wed Sep 24 00:29:08 2008 From: russm2k8 at yahoo.com (Russell Mitchell) Date: Tue, 23 Sep 2008 22:29:08 -0700 (PDT) Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer Message-ID: <167064.96544.qm@web45006.mail.sp1.yahoo.com> Hello Joe, If we can't power down the machine, due to evidence loss.?We can't?nullroute the IP, as stated, some malware will delete itself or alter itself when?Net Access is lost. Now we can filter a single port, in the case of spam, phishing, etc? I'll look further into the JunOS.?I'm not too familiar with the rules on the Juniper, so I'll take a look further, and see how to achieve this on a single IP rather then the network. Thank you for your time. Have a great day. ?--- Russell Mitchell InterCage, Inc. ----- Original Message ---- From: Joe Greco To: Russell Mitchell Cc: nanog at nanog.org Sent: Tuesday, September 23, 2008 8:20:18 PM Subject: Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer > Hello All,=0A=A0=0AIt seems you all missed the memo.=0AAs of about 11PM PST= >? Last night 09/22/08, Esthost has been ENTIRELY Shutdown. They no longer ha= > ve ANY Machine on my network.=0A=A0=0AI'm currently starting to monitor som= > e of the public media, such as google, DroneBL, as well as several Anti-Mal= > ware community websites for abuse.=0A=A0=0ABeing that Esthost is now entire= > ly GONE, we should not have any further issues.=0AIn the case that somethin= > g=A0does arise, such as an exploited host, we're currently developing a gam= > e plan for=A0response to=A0the issues.=0ATo make the best effort towards co= > mbatting=A0abuse on our network, here's what I have planned so far for ANY = > Type of abuse:=0AStep 1,=A0Suspend Power to the affected machine.=0AStep 2,= >? Call/Email the client whom the affected machine is leased to.=0AStep 3, Al= > low the client=A0the option to=A0investigate the machine further (Nullroute= >? access via KVM)=0AStep=A04, Verify the=A0reported content, domain, user, o= > r exploit=A0is patched/eliminated from the machine.=0AStep 5,=A0Remove the = > Nullroute. Allow the machine to return to the network.=0A=A0=0AAny comments= > ? =0A=A0=0AThis is=A0the result of a zero tolerance policy regarding abuse.= >? If it's clear that the server owner is the cause of the abusive material e= > tc, the client will then be immediately cancelled. No questions.=A0=0A=0A= > =0AIt seems that this approach will be the best supported by the anti-abuse= >? communities, so please let me know your input.=0A=0AThank you for your tim= > e. Have a great day.=0A=A0---=0ARussell Mitchell=0A=0AInterCage, Inc.=0A=0A= > =0A=0A----- Original Message ----=0AFrom: Paul Wall = > =0ATo: Mark Foo =0ACc: nanog at nanog.org=0ASent: Tues= > day, September 23, 2008 5:46:58 PM=0ASubject: Re: YAY! Re: Atrivo/Intercage= > : NO Upstream depeer=0A=0AHold the rejoicing, Atrivo is back, this time on = > UnitedLayer.=0A=0AI'd contact them, only they seem to change CTOs every mon= > th or two,=0Adoes anybody know who's currently in charge?=0A=0AThank you, a= > nd Drive Slow,=0APaul Wall=0A=0A=0A? ? ? Speaking of missing memos...? mailing lists are not highly compatible with HTML or some clients that like to encode list mail.? The above is what your mail looked like to some people. I would suggest a different Step 1.? Instead of killing power, simply isolate the affected machine.? This might be as simple as putting up a firewall rule or two, if it is simply sending outgoing SMTP spam, or for more complex issues, downing the port facing the machine in question. Killing the power may destroy useful forensic clues about what happened to the system, and may damage the system. ... 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 fergdawgster at gmail.com Wed Sep 24 00:52:01 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Tue, 23 Sep 2008 22:52:01 -0700 Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <548200.23333.qm@web45014.mail.sp1.yahoo.com> References: <548200.23333.qm@web45014.mail.sp1.yahoo.com> Message-ID: <6cd462c00809232252g7bed9fa5vcefb66fdd87a8912@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Sep 23, 2008 at 10:13 PM, Russell Mitchell wrote: > I believe the blocks your referring to are their 85.255 Blocks? > Registered to "InHoster". I believe those prefixes are an entity of > their's, though I don't know for sure. Perhaps ask them? > Thanks, thats right -- Inhoster. Operating out of Odessa and blacklisted virtually everywhere. Cheers, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI2dV3q1pz9mNUZTMRAvOwAKCQtLCPC+ZC3M1SVErh8kYGJ3Zp5ACaA/sE eHXtt63emWJNy/0NnVAuI6o= =xUzo -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From mark.foo.dog at gmail.com Wed Sep 24 01:08:21 2008 From: mark.foo.dog at gmail.com (Mark Foo) Date: Tue, 23 Sep 2008 23:08:21 -0700 Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <775e001a0809232047u8c8b69eq238152b7354f803@mail.gmail.com> References: <309636.9145.qm@web45004.mail.sp1.yahoo.com> <200809240320.m8O3KIw0019735@aurora.sol.net> <75cb24520809232023r6bb5820eubed1524b13acddc1@mail.gmail.com> <775e001a0809232047u8c8b69eq238152b7354f803@mail.gmail.com> Message-ID: <1bbf3c240809232308r5bb454c5ib7cd28a4612f41b5@mail.gmail.com> NANOG: Look, the people posting here who are trashing Intercage are pure security analysts -- they know and understand the evil that is Intercage. STOP TRYING TO ASSIST INTERCAGE -- you are effectively aiding and abetting the enemy. Intercage/Atrivo hosts the malware c&c botnets that DDoS your systems and networks. Intercage/Atrivo hosts the spyware that compromises your users' passwords. Intercage/Atrivo hosts the adware that slows your customers' machines. Don't take my word for it, DO YOUR OWN RESEARCH: http://www.google.com/search?hl=en&q=intercage+malware You don't get called the ***American RBN*** for hosting a couple bad machines. They have and will continue to host much of the malware pumped out of America. THEY ARE NOT YOUR COMRADES. These people represent the most HIGHLY ORGANZIED CRIME you will ever come across. Most people were afraid to speak out against them until this recent ground swell. This is the MALWARE CARTEL. GET THE PICTURE? Many links have been posted here that prove this already -- instead of asking what customers they cut off, let them show WHAT CUSTOMERS ARE LEGIT-- because there are NONE. > >> I would suggest a different Step 1. Instead of killing power, simply > >> isolate the affected machine. This might be as simple as putting up a > >> firewall rule or two, if it is simply sending outgoing SMTP spam, or > > it's probably easiest (depending on the network gear of course) to > > just put the lan port into an isolated VLAN. It's not the 100% > > solution (some badness rm's itself once it loses connectivity to the > > internets) but it'd make things simpler for the client/LEA when they > > need to figure out what happened. > > > > -chris > > > > > > From fergdawgster at gmail.com Wed Sep 24 01:11:39 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Tue, 23 Sep 2008 23:11:39 -0700 Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <6cd462c00809232252g7bed9fa5vcefb66fdd87a8912@mail.gmail.com> References: <548200.23333.qm@web45014.mail.sp1.yahoo.com> <6cd462c00809232252g7bed9fa5vcefb66fdd87a8912@mail.gmail.com> Message-ID: <6cd462c00809232311w1cf7eb0at52a02d189b790175@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Sep 23, 2008 at 10:52 PM, Paul Ferguson wrote: > On Tue, Sep 23, 2008 at 10:13 PM, Russell Mitchell > wrote: > >> I believe the blocks your referring to are their 85.255 Blocks? >> Registered to "InHoster". I believe those prefixes are an entity of >> their's, though I don't know for sure. Perhaps ask them? >> > > Thanks, thats right -- Inhoster. Operating out of Odessa and blacklisted > virtually everywhere. > Sorry, my last post on this issue. As you may (or may not) know, Inhoster's domain(s) were suspended due to criminal activity: http://whois.domaintools.com/inhoster.com The prefixes you mention, were deliberately being originated by AS27595 up until the recent kerfluffle and disconnect on Saturday night: Prefixes added and withdrawn by this origin AS in the past 7 days. - 64.28.176.0/20 Withdrawn - 67.210.0.0/21 Withdrawn - 67.210.8.0/22 Withdrawn - 67.210.14.0/23 Withdrawn - 69.22.162.0/23 Withdrawn - 69.22.168.0/21 Withdrawn - 69.22.184.0/22 Withdrawn - 69.31.64.0/20 Withdrawn - 69.50.160.0/19 Withdrawn - 85.255.113.0/24 Withdrawn - 85.255.114.0/23 Withdrawn - 85.255.116.0/22 Withdrawn - 85.255.120.0/23 Withdrawn - 85.255.122.0/24 Withdrawn - 216.255.176.0/20 Withdrawn - 216.255.176.0/22 Withdrawn - 216.255.180.0/22 Withdrawn - 216.255.184.0/22 Withdrawn - 216.255.188.0/22 Withdrawn And they magically reappeared in Cernel (AS36445) almost immediately: Prefix AS Path 64.28.187.0/24 12654 3257 36445 67.210.12.0/23 12654 3257 36445 85.255.112.0/20 12654 3257 36445 93.188.161.0/24 12654 3257 36445 93.188.166.0/24 12654 3257 36445 This was not an accident. So what you are saying is that these prefixes have always belonged to Inhoster? Thanks, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI2doTq1pz9mNUZTMRAupwAKDxEF9kyS/UoTb/Hl2FwEGM1tsj2gCfYF16 qyG0vUAmfxfdQg/vqHFCxbw= =T+0o -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From jrhett at netconsonance.com Wed Sep 24 01:16:39 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 23 Sep 2008 23:16:39 -0700 Subject: Atrivo/Intercage In-Reply-To: <200809240312.m8O3Chin019488@aurora.sol.net> References: <200809240312.m8O3Chin019488@aurora.sol.net> Message-ID: On Sep 23, 2008, at 8:12 PM, Joe Greco wrote: >> Which is not acceptable. You answer your abuse complaints, you shut >> down your spammers. Period, end of subject. > > That's a bit '90's. I'll settle for s/answer/handle/, because I don't > think that most sites are willing to actually discuss abuse issues > with > random folks submitting complaints, and so that leaves you with either > sending a form letter of some sort, or not saying anything. I went out of my way to get it written into our customer contract that we can discuss abuse issues with the affected parties. And I am simply an employee, neither an executive nor an owner, so this took a bit of doing. But it has given me great pleasure the few times that we made a mistake with a customer, and I got to tell the affected parties that the abuser is now homeless ;-) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From russm2k8 at yahoo.com Wed Sep 24 01:28:51 2008 From: russm2k8 at yahoo.com (Russell Mitchell) Date: Tue, 23 Sep 2008 23:28:51 -0700 (PDT) Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer Message-ID: <578655.69620.qm@web45006.mail.sp1.yahoo.com> Hello Paul, Sorry I didn't make this clear enough in the previous responses. The prefixes that are registered to Inhoster belong to Esthost. I'm not sure how or why you think those?prefixes belong to us. These prefixes belong DIRECTLY to us: - 69.50.160.0/19? ? ? ? ? ? ? Withdrawn - 216.255.176.0/20? ? ? ? ? ? Withdrawn These?prefixes belong DIRECTLY to nLayer, and were LEASED to us: - 69.22.162.0/23? ? ? ? ? ? ? Withdrawn - 69.22.168.0/21? ? ? ? ? ? ? Withdrawn - 69.22.184.0/22? ? ? ? ? ? ? Withdrawn - 69.31.64.0/20? ? ? ? ? ? ? Withdrawn ? The prefixes LEASED to us BY nLayer are being reclaimed at the end of this month 09/30/08, as the lease contract is set to cease at that time. Hopefully, that is clear enough for you. Thank you for your time. Have a great day. --- Russell Mitchell InterCage, Inc. ----- Original Message ---- From: Paul Ferguson To: Russell Mitchell Cc: nanog at nanog.org Sent: Tuesday, September 23, 2008 11:11:39 PM Subject: Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Sep 23, 2008 at 10:52 PM, Paul Ferguson wrote: > On Tue, Sep 23, 2008 at 10:13 PM, Russell Mitchell > wrote: > >> I believe the blocks your referring to are their 85.255 Blocks? >> Registered to "InHoster". I believe those prefixes are an entity of >> their's, though I don't know for sure. Perhaps ask them? >> > > Thanks, thats right -- Inhoster. Operating out of Odessa and blacklisted > virtually everywhere. > Sorry, my last post on this issue. As you may (or may not) know, Inhoster's domain(s) were suspended due to criminal activity: http://whois.domaintools.com/inhoster.com The prefixes you mention, were deliberately being originated by AS27595? up until the recent kerfluffle and disconnect on Saturday night: ? ? Prefixes added and withdrawn by this origin AS in the past 7 days. ? ? ? ? ? - 64.28.176.0/20? ? ? ? ? ? ? Withdrawn ? ? ? ? ? - 67.210.0.0/21? ? ? ? ? ? ? Withdrawn ? ? ? ? ? - 67.210.8.0/22? ? ? ? ? ? ? Withdrawn ? ? ? ? ? - 67.210.14.0/23? ? ? ? ? ? ? Withdrawn ? ? ? ? ? - 69.22.162.0/23? ? ? ? ? ? ? Withdrawn ? ? ? ? ? - 69.22.168.0/21? ? ? ? ? ? ? Withdrawn ? ? ? ? ? - 69.22.184.0/22? ? ? ? ? ? ? Withdrawn ? ? ? ? ? - 69.31.64.0/20? ? ? ? ? ? ? Withdrawn ? ? ? ? ? - 69.50.160.0/19? ? ? ? ? ? ? Withdrawn ? ? ? ? ? - 85.255.113.0/24? ? ? ? ? ? Withdrawn ? ? ? ? ? - 85.255.114.0/23? ? ? ? ? ? Withdrawn ? ? ? ? ? - 85.255.116.0/22? ? ? ? ? ? Withdrawn ? ? ? ? ? - 85.255.120.0/23? ? ? ? ? ? Withdrawn ? ? ? ? ? - 85.255.122.0/24? ? ? ? ? ? Withdrawn ? ? ? ? ? - 216.255.176.0/20? ? ? ? ? ? Withdrawn ? ? ? ? ? - 216.255.176.0/22? ? ? ? ? ? Withdrawn ? ? ? ? ? - 216.255.180.0/22? ? ? ? ? ? Withdrawn ? ? ? ? ? - 216.255.184.0/22? ? ? ? ? ? Withdrawn ? ? ? ? ? - 216.255.188.0/22? ? ? ? ? ? Withdrawn And they magically reappeared in Cernel (AS36445) almost immediately: Prefix? ? ? ? ? ? ? AS Path ? 64.28.187.0/24? ? ? 12654 3257 36445 ? 67.210.12.0/23? ? ? 12654 3257 36445 ? 85.255.112.0/20? ? ? 12654 3257 36445 ? 93.188.161.0/24? ? ? 12654 3257 36445 ? 93.188.166.0/24? ? ? 12654 3257 36445 This was not an accident. So what you are saying is that these prefixes have always belonged to Inhoster? Thanks, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI2doTq1pz9mNUZTMRAupwAKDxEF9kyS/UoTb/Hl2FwEGM1tsj2gCfYF16 qyG0vUAmfxfdQg/vqHFCxbw= =T+0o -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From fergdawgster at gmail.com Wed Sep 24 01:31:18 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Tue, 23 Sep 2008 23:31:18 -0700 Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <578655.69620.qm@web45006.mail.sp1.yahoo.com> References: <578655.69620.qm@web45006.mail.sp1.yahoo.com> Message-ID: <6cd462c00809232331k196a5050y6929ee8e809bef32@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Sep 23, 2008 at 11:28 PM, Russell Mitchell wrote: > Sorry I didn't make this clear enough in the previous responses. > > The prefixes that are registered to Inhoster belong to Esthost. > I'm not sure how or why you think those prefixes belong to us. > > These prefixes belong DIRECTLY to us: > - 69.50.160.0/19 Withdrawn > - 216.255.176.0/20 Withdrawn > > These prefixes belong DIRECTLY to nLayer, and were LEASED to us: > - 69.22.162.0/23 Withdrawn > - 69.22.168.0/21 Withdrawn > - 69.22.184.0/22 Withdrawn > - 69.31.64.0/20 Withdrawn > > The prefixes LEASED to us BY nLayer are being reclaimed at the end of > this month 09/30/08, as the lease contract is set to cease at that time. > > Hopefully, that is clear enough for you. > > Thank you for your time. Have a great day. > --- > Russell Mitchell > > InterCage, Inc. > Clear as mud, thanks. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI2d6uq1pz9mNUZTMRAmkcAJ4toRsggJ325VfjkqK8QJKWQG4UegCg84x+ KwcuyxtFp7/x3/vScFTkP3I= =/vFy -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From pmessri at gmail.com Wed Sep 24 01:38:54 2008 From: pmessri at gmail.com (Pedram M) Date: Tue, 23 Sep 2008 23:38:54 -0700 Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <6cd462c00809232331k196a5050y6929ee8e809bef32@mail.gmail.com> References: <578655.69620.qm@web45006.mail.sp1.yahoo.com> <6cd462c00809232331k196a5050y6929ee8e809bef32@mail.gmail.com> Message-ID: <9c9aa5d00809232338h41c76d12l24f2c106b80ca613@mail.gmail.com> Wow, this topic has really gotten old. On Tue, Sep 23, 2008 at 11:31 PM, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tue, Sep 23, 2008 at 11:28 PM, Russell Mitchell > wrote: > > > > Sorry I didn't make this clear enough in the previous responses. > > > > The prefixes that are registered to Inhoster belong to Esthost. > > I'm not sure how or why you think those prefixes belong to us. > > > > These prefixes belong DIRECTLY to us: > > - 69.50.160.0/19 Withdrawn > > - 216.255.176.0/20 Withdrawn > > > > These prefixes belong DIRECTLY to nLayer, and were LEASED to us: > > - 69.22.162.0/23 Withdrawn > > - 69.22.168.0/21 Withdrawn > > - 69.22.184.0/22 Withdrawn > > - 69.31.64.0/20 Withdrawn > > > > The prefixes LEASED to us BY nLayer are being reclaimed at the end of > > this month 09/30/08, as the lease contract is set to cease at that time. > > > > Hopefully, that is clear enough for you. > > > > Thank you for your time. Have a great day. > > --- > > Russell Mitchell > > > > InterCage, Inc. > > > > Clear as mud, thanks. > > - - ferg > > -----BEGIN PGP SIGNATURE----- > Version: PGP Desktop 9.6.3 (Build 3017) > > wj8DBQFI2d6uq1pz9mNUZTMRAmkcAJ4toRsggJ325VfjkqK8QJKWQG4UegCg84x+ > KwcuyxtFp7/x3/vScFTkP3I= > =/vFy > -----END PGP SIGNATURE----- > > > -- > "Fergie", a.k.a. Paul Ferguson > Engineering Architecture for the Internet > fergdawgster(at)gmail.com > ferg's tech blog: http://fergdawg.blogspot.com/ > > From russm2k8 at yahoo.com Wed Sep 24 01:50:11 2008 From: russm2k8 at yahoo.com (Russell Mitchell) Date: Tue, 23 Sep 2008 23:50:11 -0700 (PDT) Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer Message-ID: <583194.37265.qm@web45002.mail.sp1.yahoo.com> Hello?John Doe, I welcome any further comments you have. We have to get past people such as yourself, and your blasphemous and false statements. This is the same issue with the recent?media and self-proclaimed "Security Researchers". Fly-by-night mind you. To help you out in your claims: Yes, we did house a client whom had quite a?run with?their client's from?various?locations, such as Russia. That Client is no longer hosted on our network. I myself spent all of monday afternoon, night, and tuesday morning shutting off EVERY machine they had leased in our Billing System. I'm currently working to scan further and see if there's anything I may have missed. Yes, Russia is?very well known for Virus and Malware writer's. Yes, we have had issues with malware distribution from our network. This was directly and near singularly related to the?former client of ours. We did have another client, Hostfresh, whom had their share of malware issues. Both have been completely and effectively removed. The server's leased to?both of them have been canceled, and their machines have been shutoff. Let me know if there's anything else you'd like me to state to the public. We're on a rocky road right now. But it IS starting to smooth out. Thank you for your time. Have a great day. ?--- Russell Mitchell InterCage, Inc. ----- Original Message ---- From: Mark Foo To: Bruce Williams Cc: Christopher Morrow ; nanog at nanog.org; Joe Greco Sent: Tuesday, September 23, 2008 11:08:21 PM Subject: Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer NANOG: Look, the people posting here who are trashing Intercage are pure security analysts -- they know and understand the evil that is Intercage. STOP TRYING TO ASSIST INTERCAGE -- you are effectively aiding and abetting the enemy. Intercage/Atrivo hosts the malware c&c botnets that DDoS your systems and networks. Intercage/Atrivo hosts the spyware that compromises your users' passwords. Intercage/Atrivo hosts the adware that slows your customers' machines. Don't take my word for it, DO YOUR OWN RESEARCH: http://www.google.com/search?hl=en&q=intercage+malware You don't get called the ***American RBN*** for hosting a couple bad machines. They have and will continue to host much of the malware pumped out of America. THEY ARE NOT YOUR COMRADES.. These people represent the most HIGHLY ORGANZIED CRIME you will ever come across. Most people were afraid to speak out against them until this recent ground swell. This is the MALWARE CARTEL. GET THE PICTURE? Many links have been posted here that prove this already -- instead of asking what customers they cut off, let them show WHAT CUSTOMERS ARE LEGIT-- because there are NONE. > >> I would suggest a different Step 1.? Instead of killing power, simply > >> isolate the affected machine.? This might be as simple as putting up a > >> firewall rule or two, if it is simply sending outgoing SMTP spam, or > > it's probably easiest (depending on the network gear of course) to > > just put the lan port into an isolated VLAN. It's not the 100% > > solution (some badness rm's itself once it loses connectivity to the > > internets) but it'd make things simpler for the client/LEA when they > > need to figure out what happened. > > > > -chris > > > > > > From russm2k8 at yahoo.com Wed Sep 24 02:12:28 2008 From: russm2k8 at yahoo.com (Russell Mitchell) Date: Wed, 24 Sep 2008 00:12:28 -0700 (PDT) Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer Message-ID: <656700.40561.qm@web45008.mail.sp1.yahoo.com> Hello Pedram, Until everyone fully understands the truth in ENGLISH, this?topic will continue. This is what they demand. As long as there are questions which relate to us, I will?continue to respond. When it's set in stone, and the false claims and false statements are corrected, this topic will cease. I hope soon, people will realise and accept the truth that we are a LEGITIMATE Company that DOES Operate in the USA. We are NOT directly or in-directly related to any Russian's. We do NOT support, write, directly distribute, or knowingly allow the distribution of malware or other abusive activities to originate from our network. While the previous statements are questionable in the public's eye, I hope some time, you will understand it IS the truth. Prove me wrong, PLEASE. If you know of any further malware or further abusive activities, such as the claimed C&C Botnets, please PLEASE don't hesitate to tell me. abuse.intercage and russ..intercage and?emil.intercage?are live and operational. We are currently?investigating the rest of our clientel and any site's or communities you can recommend to?follow, we will?follow.? While it is clear that this?will not be accepted by the community any time soon, it will eventually be accepted. That is what I am waiting for, however long it takes. I can't stress this enough. We DO need your help to locate and eliminate abusive activities from our network. I know you have information, and I need you to atleast reclaim the faith that we WILL be very active against abuse originating from our network, and we WILL be proactive to locate and eliminate abusive activities on our network. Thank you very much for all your time and future assistance. Have a great day. --- Russell Mitchell InterCage, Inc. ----- Original Message ---- From: Pedram M To: nanog at nanog.org Sent: Tuesday, September 23, 2008 11:38:54 PM Subject: Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer Wow, this topic has really gotten old. On Tue, Sep 23, 2008 at 11:31 PM, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tue, Sep 23, 2008 at 11:28 PM, Russell Mitchell > wrote: > > > > Sorry I didn't make this clear enough in the previous responses. > > > > The prefixes that are registered to Inhoster belong to Esthost. > > I'm not sure how or why you think those prefixes belong to us. > > > > These prefixes belong DIRECTLY to us: > > - 69.50.160.0/19? ? ? ? ? ? ? Withdrawn > > - 216.255.176.0/20? ? ? ? ? ? Withdrawn > > > > These prefixes belong DIRECTLY to nLayer, and were LEASED to us: > > - 69.22.162.0/23? ? ? ? ? ? ? Withdrawn > > - 69.22.168.0/21? ? ? ? ? ? ? Withdrawn > > - 69.22.184.0/22? ? ? ? ? ? ? Withdrawn > > - 69.31.64.0/20? ? ? ? ? ? ? Withdrawn > > > > The prefixes LEASED to us BY nLayer are being reclaimed at the end of > > this month 09/30/08, as the lease contract is set to cease at that time. > > > > Hopefully, that is clear enough for you. > > > > Thank you for your time. Have a great day. > > --- > > Russell Mitchell > > > > InterCage, Inc. > > > > Clear as mud, thanks. > > - - ferg > > -----BEGIN PGP SIGNATURE----- > Version: PGP Desktop 9.6.3 (Build 3017) > > wj8DBQFI2d6uq1pz9mNUZTMRAmkcAJ4toRsggJ325VfjkqK8QJKWQG4UegCg84x+ > KwcuyxtFp7/x3/vScFTkP3I= > =/vFy > -----END PGP SIGNATURE----- > > > -- > "Fergie", a.k.a. Paul Ferguson >? Engineering Architecture for the Internet >? fergdawgster(at)gmail.com >? ferg's tech blog: http://fergdawg.blogspot.com/ > > From fergdawgster at gmail.com Wed Sep 24 02:20:59 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 24 Sep 2008 00:20:59 -0700 Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <656700.40561.qm@web45008.mail.sp1.yahoo.com> References: <656700.40561.qm@web45008.mail.sp1.yahoo.com> Message-ID: <6cd462c00809240020v3e68612fn17356acdbb25adcc@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Sep 24, 2008 at 12:12 AM, Russell Mitchell wrote: > > I hope soon, people will realise and accept the truth that we are a > LEGITIMATE Company that DOES Operate in the USA. We are NOT directly or > in-directly related to any Russian's. We do NOT support, write, directly > distribute, or knowingly allow the distribution of malware or other > abusive activities to originate from our network. While the previous > statements are questionable in the public's eye, I hope some time, you > will understand it IS the truth. > > Prove me wrong, PLEASE. AS27595, and all prefixes which you advertise, will be ultra-scrutinized. You can be sure that you, and many others, will know if & when criminal activity re-appears inside prefixes hosted by Atrivo/Intercage. The gloves are off, so to speak. Cheers, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI2epPq1pz9mNUZTMRAumJAKD5lujVV7CTeZ6iQDEjsELHy7+I1wCfeXFH TxVWvBONxa+jozHf9hq+k2c= =L/4x -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From russm2k8 at yahoo.com Wed Sep 24 02:25:02 2008 From: russm2k8 at yahoo.com (Russell Mitchell) Date: Wed, 24 Sep 2008 00:25:02 -0700 (PDT) Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer Message-ID: <722664.49787.qm@web45003.mail.sp1.yahoo.com> Hello Paul, GREAT! I am very pleased with that. This is what we need, and I'm sure you can agree, this is what the Internet needs. Thank you very much for your time.?Have a great day. ?--- Russell Mitchell InterCage, Inc. ----- Original Message ---- From: Paul Ferguson To: Russell Mitchell Cc: nanog at nanog.org Sent: Wednesday, September 24, 2008 12:20:59 AM Subject: Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Sep 24, 2008 at 12:12 AM, Russell Mitchell wrote: > > I hope soon, people will realise and accept the truth that we are a > LEGITIMATE Company that DOES Operate in the USA. We are NOT directly or > in-directly related to any Russian's. We do NOT support, write, directly > distribute, or knowingly allow the distribution of malware or other > abusive activities to originate from our network. While the previous > statements are questionable in the public's eye, I hope some time, you > will understand it IS the truth. > > Prove me wrong, PLEASE. AS27595, and all prefixes which you advertise, will be ultra-scrutinized. You can be sure that you, and many others, will know if & when criminal activity re-appears inside prefixes hosted by Atrivo/Intercage. The gloves are off, so to speak. Cheers, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI2epPq1pz9mNUZTMRAumJAKD5lujVV7CTeZ6iQDEjsELHy7+I1wCfeXFH TxVWvBONxa+jozHf9hq+k2c= =L/4x -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From mark.foo.dog at gmail.com Wed Sep 24 02:27:50 2008 From: mark.foo.dog at gmail.com (Mark Foo) Date: Wed, 24 Sep 2008 00:27:50 -0700 Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <583194.37265.qm@web45002.mail.sp1.yahoo.com> References: <583194.37265.qm@web45002.mail.sp1.yahoo.com> Message-ID: <1bbf3c240809240027w6d660a0ew97eb25eaa11d52c8@mail.gmail.com> Russell: Ferg was just being coy -- what you don't understand is there are about 3 other security mailing lists plotting to TAKE YOUR SERVICE DOWN. You FAIL. Law Enforcement might not take action against you (but appear to be interested now), but the community can. GET OFF THE NET WITH YOUR MALWARE! You mistake me for someone who believes you pack of lies! Don't you understand each time you post to this list gives those of us who know the opportunity to post MORE EVIDENCE of your MALWARE? You disconnected Hostfresh and think that's the extent of your cimes? Gimme a break. Only those who are easily socially engineered would believe your pathetic claims of innocence. You've BEEN HOSTING MALWARE since 2003 -- SEE Nanog post: Re: The in-your-face hijacking example http://www.irbs.net/internet/nanog/0305/0038.html > Let me know if there's anything else you'd like me to state to the public. Answer Ferg's question -- Why are you moving to CERNAL? Do you think this is going to work? That's just another of Emil's networks. > We're on a rocky road right now. But it IS starting to smooth out. That's just the calm before the storm. Go ahead and post a response to each of these allegations: Cybercrime's US Hosts http://www.spamhaus.org/news.lasso?article=636 Report Slams U.S. Host as Major Source of Badware http://voices.washingtonpost.com/securityfix/2008/08/report_slams_us_host_as_major.html?nav=rss_blog A Superlative Scam and Spam Site Registrar http://voices.washingtonpost.com/securityfix/2008/09/estdomains.html?nav=rss_blog ICANN cast as online scam enabler http://www.theregister.co.uk/2008/09/03/cyber_crime_reports/ 'Malware-friendly' Intercage back with the living http://www.theregister.co.uk/2008/09/24/intercage_back_online/ On Tue, Sep 23, 2008 at 11:50 PM, Russell Mitchell wrote: > > Hello John Doe, > > I welcome any further comments you have. > We have to get past people such as yourself, and your blasphemous and false statements. > > This is the same issue with the recent media and self-proclaimed "Security Researchers". Fly-by-night mind you. > > To help you out in your claims: > Yes, we did house a client whom had quite a run with their client's from various locations, such as Russia. > That Client is no longer hosted on our network. I myself spent all of monday afternoon, night, and tuesday morning shutting off EVERY machine they had leased in our Billing System. I'm currently working to scan further and see if there's anything I may have missed. > > Yes, Russia is very well known for Virus and Malware writer's. > > Yes, we have had issues with malware distribution from our network. > This was directly and near singularly related to the former client of ours. We did have another client, Hostfresh, whom had their share of malware issues. > > Both have been completely and effectively removed. The server's leased to both of them have been canceled, and their machines have been shutoff. > > Let me know if there's anything else you'd like me to state to the public. > We're on a rocky road right now. But it IS starting to smooth out. > > Thank you for your time. Have a great day. > --- > Russell Mitchell > > InterCage, Inc. > > > > ----- Original Message ---- > From: Mark Foo > To: Bruce Williams > Cc: Christopher Morrow ; nanog at nanog.org; Joe Greco > Sent: Tuesday, September 23, 2008 11:08:21 PM > Subject: Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer > > NANOG: > > Look, the people posting here who are trashing Intercage are pure security > analysts -- they > know and understand the evil that is Intercage. STOP TRYING TO ASSIST > INTERCAGE > -- you are effectively aiding and abetting the enemy. > > Intercage/Atrivo hosts the malware c&c botnets that DDoS your systems and > networks. > > Intercage/Atrivo hosts the spyware that compromises your users' passwords. > > Intercage/Atrivo hosts the adware that slows your customers' machines. > > Don't take my word for it, DO YOUR OWN RESEARCH: > http://www.google.com/search?hl=en&q=intercage+malware > > You don't get called the ***American RBN*** for hosting a couple bad > machines. They > have and will continue to host much of the malware pumped out of America. > THEY > ARE NOT YOUR COMRADES.. > > These people represent the most HIGHLY ORGANZIED CRIME you will ever > come across. Most people were afraid to speak out against them until this > recent ground swell. > > This is the MALWARE CARTEL. GET THE PICTURE? > > Many links have been posted here that prove this already -- instead of > asking > what customers they cut off, let them show WHAT CUSTOMERS ARE LEGIT-- > because there are NONE. > > > > > > > >> I would suggest a different Step 1. Instead of killing power, simply > > >> isolate the affected machine. This might be as simple as putting up a > > >> firewall rule or two, if it is simply sending outgoing SMTP spam, or > > > it's probably easiest (depending on the network gear of course) to > > > just put the lan port into an isolated VLAN. It's not the 100% > > > solution (some badness rm's itself once it loses connectivity to the > > > internets) but it'd make things simpler for the client/LEA when they > > > need to figure out what happened. > > > > > > -chris > > > > > > > > > > > > > > > From fergdawgster at gmail.com Wed Sep 24 02:38:07 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 24 Sep 2008 00:38:07 -0700 Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <1bbf3c240809240027w6d660a0ew97eb25eaa11d52c8@mail.gmail.com> References: <583194.37265.qm@web45002.mail.sp1.yahoo.com> <1bbf3c240809240027w6d660a0ew97eb25eaa11d52c8@mail.gmail.com> Message-ID: <6cd462c00809240038gc76350csc25e1c3d1cc87f1c@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Sep 24, 2008 at 12:27 AM, Mark Foo wrote: > Answer Ferg's question -- Why are you moving to CERNAL? Do you think this > is going to work? That's just another of Emil's networks. > Actually, I was not being coy. Okay, maybe I was. With regards to the "prefix shuffle" to Cernel, I think that speaks for itself. With regards to "...another of Emil's networks...", I don't believe that to be true. In fact, I think Emil is just a pawn in this entire mess. It is clear to me -- at least -- that this entire criminal operation is being operated out of Eastern Europe, and their foothold in the U.S. is the major issue here. This is the major heartburn -- ISPs and network operators in the U.S. seem not to care about these issues, and it becomes an 'unpopular' effort to purge these activities in this audience. $.02, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI2e5Wq1pz9mNUZTMRAsf6AJ47BKaCBckIkllV2XN/CJhvIGUqowCgrOSQ kBmKYLTVEipzNwXGxIZa6Zo= =zs8t -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From russm2k8 at yahoo.com Wed Sep 24 02:45:37 2008 From: russm2k8 at yahoo.com (Russell Mitchell) Date: Wed, 24 Sep 2008 00:45:37 -0700 (PDT) Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer Message-ID: <419009.17896.qm@web45010.mail.sp1.yahoo.com> Hello Mark, It?really seems?YOU _DID_ miss the memo. I think that?since no one else is responding to your non-sense, there is no reason for me to either. If you have something accurate?to say, I'll be happy to listen. Until then, there's not much I can say. There's no sense in repeating myself. ?--- Russell Mitchell InterCage, Inc. ----- Original Message ---- From: Mark Foo To: Russell Mitchell Cc: Bruce Williams ; Christopher Morrow ; nanog at nanog.org; Joe Greco Sent: Wednesday, September 24, 2008 12:27:50 AM Subject: Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer Russell: Ferg was just being coy -- what you don't understand is there are about 3 other security mailing lists plotting to TAKE YOUR SERVICE DOWN. You FAIL. Law Enforcement might not take action against you (but appear to be interested now), but the community can. GET OFF THE NET WITH YOUR MALWARE! You mistake me for someone who believes you pack of lies! Don't you understand each time you post to this list gives those of us who know the opportunity to post MORE EVIDENCE of your MALWARE? You disconnected Hostfresh and think that's the extent of your cimes? Gimme a break. Only those who are easily socially engineered would believe your pathetic claims of innocence. You've BEEN HOSTING MALWARE since 2003 -- SEE Nanog post: Re: The in-your-face hijacking example http://www.irbs.net/internet/nanog/0305/0038.html > Let me know if there's anything else you'd like me to state to the public. Answer Ferg's question -- Why are you moving to CERNAL? Do you think this is going to work? That's just another of Emil's networks. > We're on a rocky road right now. But it IS starting to smooth out. That's just the calm before the storm. Go ahead and post a response to each of these allegations: Cybercrime's US Hosts http://www.spamhaus.org/news.lasso?article=636 Report Slams U.S. Host as Major Source of Badware http://voices.washingtonpost.com/securityfix/2008/08/report_slams_us_host_as_major.html?nav=rss_blog A Superlative Scam and Spam Site Registrar http://voices.washingtonpost.com/securityfix/2008/09/estdomains.html?nav=rss_blog ICANN cast as online scam enabler http://www.theregister.co.uk/2008/09/03/cyber_crime_reports/ 'Malware-friendly' Intercage back with the living http://www.theregister.co.uk/2008/09/24/intercage_back_online/ On Tue, Sep 23, 2008 at 11:50 PM, Russell Mitchell wrote: > > Hello John Doe, > > I welcome any further comments you have. > We have to get past people such as yourself, and your blasphemous and false statements. > > This is the same issue with the recent media and self-proclaimed "Security Researchers". Fly-by-night mind you. > > To help you out in your claims: > Yes, we did house a client whom had quite a run with their client's from various locations, such as Russia. > That Client is no longer hosted on our network. I myself spent all of monday afternoon, night, and tuesday morning shutting off EVERY machine they had leased in our Billing System. I'm currently working to scan further and see if there's anything I may have missed. > > Yes, Russia is very well known for Virus and Malware writer's. > > Yes, we have had issues with malware distribution from our network. > This was directly and near singularly related to the former client of ours. We did have another client, Hostfresh, whom had their share of malware issues. > > Both have been completely and effectively removed. The server's leased to both of them have been canceled, and their machines have been shutoff. > > Let me know if there's anything else you'd like me to state to the public. > We're on a rocky road right now. But it IS starting to smooth out. > > Thank you for your time. Have a great day. >? --- > Russell Mitchell > > InterCage, Inc. > > > > ----- Original Message ---- > From: Mark Foo > To: Bruce Williams > Cc: Christopher Morrow ; nanog at nanog.org; Joe Greco > Sent: Tuesday, September 23, 2008 11:08:21 PM > Subject: Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer > > NANOG: > > Look, the people posting here who are trashing Intercage are pure security > analysts -- they > know and understand the evil that is Intercage. STOP TRYING TO ASSIST > INTERCAGE > -- you are effectively aiding and abetting the enemy. > > Intercage/Atrivo hosts the malware c&c botnets that DDoS your systems and > networks. > > Intercage/Atrivo hosts the spyware that compromises your users' passwords. > > Intercage/Atrivo hosts the adware that slows your customers' machines. > > Don't take my word for it, DO YOUR OWN RESEARCH: > http://www.google.com/search?hl=en&q=intercage+malware > > You don't get called the ***American RBN*** for hosting a couple bad > machines. They > have and will continue to host much of the malware pumped out of America. > THEY > ARE NOT YOUR COMRADES.. > > These people represent the most HIGHLY ORGANZIED CRIME you will ever > come across. Most people were afraid to speak out against them until this > recent ground swell. > > This is the MALWARE CARTEL. GET THE PICTURE? > > Many links have been posted here that prove this already -- instead of > asking > what customers they cut off, let them show WHAT CUSTOMERS ARE LEGIT-- > because there are NONE. > > > > > > > >> I would suggest a different Step 1.? Instead of killing power, simply > > >> isolate the affected machine.? This might be as simple as putting up a > > >> firewall rule or two, if it is simply sending outgoing SMTP spam, or > > > it's probably easiest (depending on the network gear of course) to > > > just put the lan port into an isolated VLAN. It's not the 100% > > > solution (some badness rm's itself once it loses connectivity to the > > > internets) but it'd make things simpler for the client/LEA when they > > > need to figure out what happened. > > > > > > -chris > > > > > > > > > > > > > > > From mark.foo.dog at gmail.com Wed Sep 24 03:14:01 2008 From: mark.foo.dog at gmail.com (Mark Foo) Date: Wed, 24 Sep 2008 01:14:01 -0700 Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <419009.17896.qm@web45010.mail.sp1.yahoo.com> References: <419009.17896.qm@web45010.mail.sp1.yahoo.com> Message-ID: <1bbf3c240809240114rdd80e46p90dbe4da1a34e3fd@mail.gmail.com> Russell: Oh I got the memo, you'll be getting served one soon too. I just wonder why you don't consider playing both sides of the fence -- with your knowledge of who's who in the cyber crime field, you could probably get paid more as an informant (either to LEO or one of the "Intel" companies than whatever you're doing for Emil and (allegedly) the RBN. You can't possible sleep well knowing what your up to now so I figure it's the money that motivates you. Or, maybe you don't really know anyone, you just respond to their demands and they end up with all the money, pr0n chicks, etc. Doesn't that bother you -- don't you want more? Plus, no one would know you were pulling two pay checks -- you manage systems on one side and pass info to the other. It's actually fairly simple -- maybe you already know this ;). If not, please explain this: http://www.spamhaus.org/news.lasso?article=636 Without exception, all of the major security organizations on the Internet agree that the 'Home' of cybercrime in the western world is a firm known as Atrivo/Intercage, based in California. We ourselves have not come to this conclusion lightly but from many years of dealing with criminal operations hosted by Atrivo/Intercage, gangs of cybercriminals - mostly Russian and East European but with several US online crime gangs as well - whose activities always lead back to servers run by Atrivo/Intercage. We have lost count of the times we have tracked a major virus botnet's "command and control" to Atrivo/Intercage servers, readers can view here some of the current and historic SBL records for Atrivo for a taste of what has been happening in this network. At almost every Internet security conference, or law enforcement seminar on cyber-crime, a presentation will detail some attack, exploit, phish or financial crime that has some nexus at Atrivo/Intercage. The person who runs Atrivo/Intercage, Emil Kacperski is an expert at playing the "surprised janitor", unaware of every new criminal enterprise found on his servers and keen to show he gets rid of some criminals once their activities on his network are exposed. His Internet hosting career first came to the attention of most anti-abuse organizations when he pinched (or 'purchased stolen goods' as he put it) and routed an unused block of 65,536 IP addresses belonging to the County of Los Angeles. Spamhaus has dealt with over 350 incidents of cyber-crime hosting on Atrivo/Intercage and its related networks in the last 3 years alone, all of which involved criminal operations such as malware, virus spreaders and botnet command and control servers. Malware found by Spamhaus on Atrivo/Intercage/Cernel/Hostfresh just in the last few months included the Storm Worm installer and controller and a MySpace spambot amongst others. Spamhaus currently sees a large amount of activity related to malicious software and exploits being hosted on Atrivo/Intercage which include DNS hijack malware, IFRAME browser attacks, dialers, pirated software websites and blatantly criminal services. We assume that every law enforcement agency with a cyber-crimes division has a dossier bursting at the seams on Atrivo/Intercage and its tentacles such as Esthost, Estdomains, Cernel, Hostfresh. The only question on everyone's mind is which agency will beat the others to shutting the whole place down and indicting the people behind it. Because if shut down, one thing is certain: the amount of malware-driven crime on the Internet would drop overnight as cyber-criminals rush to find a new crime-friendly host - difficult to find in the US, as Atrivo/Intercage is one of the very few remaining dedicated crime hosting firms whose customer base is composed almost, or perhaps entirely, of criminal gangs. More importantly, millions of Internet users currently being targeted by the malware gangs operating from Atrivo/Intercage will be, for a while, safer. Perhaps one may be wondering about the costs of hosting at Atrivo/Intercage or how to sign up? Well, don't expect to find this information at the company's websites as they were empty for years and for the last year have just shown "Website Coming Soon." http://www.atrivo.com => "InterCage, Inc. INTENSE SERVERS. Website Coming Soon:" Last Updated: Thursday, September 06, 2007 4:32:59 PM http://www.intercage.com => "InterCage, Inc. INTENSE SERVERS. Website Coming Soon:" Tuesday, September 04, 2007 6:45:52 PM At one time after being asked, "how on earth does your company get business?" an Atrivo/Intercage representative coyly said, "by word of mouth." That seems to be quite obvious. On Wed, Sep 24, 2008 at 12:45 AM, Russell Mitchell wrote: > Hello Mark, > > It really seems YOU _DID_ miss the memo. > I think that since no one else is responding to your non-sense, there is no reason for me to either. > > If you have something accurate to say, I'll be happy to listen. > Until then, there's not much I can say. There's no sense in repeating myself. > --- > Russell Mitchell > > InterCage, Inc. > > > > ----- Original Message ---- > From: Mark Foo > To: Russell Mitchell > Cc: Bruce Williams ; Christopher Morrow ; nanog at nanog.org; Joe Greco > Sent: Wednesday, September 24, 2008 12:27:50 AM > Subject: Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer > > Russell: > > Ferg was just being coy -- what you don't understand is there are about 3 other > security mailing lists plotting to TAKE YOUR SERVICE DOWN. You FAIL. Law > Enforcement might not take action against you (but appear to be interested now), > but the community can. GET OFF THE NET WITH YOUR MALWARE! > > You mistake me for someone who believes you pack of lies! Don't you > understand each > time you post to this list gives those of us who know the opportunity > to post MORE EVIDENCE > of your MALWARE? > > You disconnected Hostfresh and think that's the extent of your cimes? > Gimme a break. > Only those who are easily socially engineered would believe your > pathetic claims of innocence. > You've BEEN HOSTING MALWARE since 2003 -- SEE Nanog post: > > Re: The in-your-face hijacking example > http://www.irbs.net/internet/nanog/0305/0038.html > >> Let me know if there's anything else you'd like me to state to the public. > > Answer Ferg's question -- Why are you moving to CERNAL? Do you think this > is going to work? That's just another of Emil's networks. > >> We're on a rocky road right now. But it IS starting to smooth out. > > That's just the calm before the storm. > > Go ahead and post a response to each of these allegations: > > Cybercrime's US Hosts > http://www.spamhaus.org/news.lasso?article=636 > > Report Slams U.S. Host as Major Source of Badware > http://voices.washingtonpost.com/securityfix/2008/08/report_slams_us_host_as_major.html?nav=rss_blog > > A Superlative Scam and Spam Site Registrar > http://voices.washingtonpost.com/securityfix/2008/09/estdomains.html?nav=rss_blog > > ICANN cast as online scam enabler > http://www.theregister.co.uk/2008/09/03/cyber_crime_reports/ > > 'Malware-friendly' Intercage back with the living > http://www.theregister.co.uk/2008/09/24/intercage_back_online/ > > > > > > > > > On Tue, Sep 23, 2008 at 11:50 PM, Russell Mitchell wrote: >> >> Hello John Doe, >> >> I welcome any further comments you have. >> We have to get past people such as yourself, and your blasphemous and false statements. >> >> This is the same issue with the recent media and self-proclaimed "Security Researchers". Fly-by-night mind you. >> >> To help you out in your claims: >> Yes, we did house a client whom had quite a run with their client's from various locations, such as Russia. >> That Client is no longer hosted on our network. I myself spent all of monday afternoon, night, and tuesday morning shutting off EVERY machine they had leased in our Billing System. I'm currently working to scan further and see if there's anything I may have missed. >> >> Yes, Russia is very well known for Virus and Malware writer's. >> >> Yes, we have had issues with malware distribution from our network. >> This was directly and near singularly related to the former client of ours. We did have another client, Hostfresh, whom had their share of malware issues. >> >> Both have been completely and effectively removed. The server's leased to both of them have been canceled, and their machines have been shutoff. >> >> Let me know if there's anything else you'd like me to state to the public. >> We're on a rocky road right now. But it IS starting to smooth out. >> >> Thank you for your time. Have a great day. >> --- >> Russell Mitchell >> >> InterCage, Inc. >> >> >> >> ----- Original Message ---- >> From: Mark Foo >> To: Bruce Williams >> Cc: Christopher Morrow ; nanog at nanog.org; Joe Greco >> Sent: Tuesday, September 23, 2008 11:08:21 PM >> Subject: Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer >> >> NANOG: >> >> Look, the people posting here who are trashing Intercage are pure security >> analysts -- they >> know and understand the evil that is Intercage. STOP TRYING TO ASSIST >> INTERCAGE >> -- you are effectively aiding and abetting the enemy. >> >> Intercage/Atrivo hosts the malware c&c botnets that DDoS your systems and >> networks. >> >> Intercage/Atrivo hosts the spyware that compromises your users' passwords. >> >> Intercage/Atrivo hosts the adware that slows your customers' machines. >> >> Don't take my word for it, DO YOUR OWN RESEARCH: >> http://www.google.com/search?hl=en&q=intercage+malware >> >> You don't get called the ***American RBN*** for hosting a couple bad >> machines. They >> have and will continue to host much of the malware pumped out of America. >> THEY >> ARE NOT YOUR COMRADES.. >> >> These people represent the most HIGHLY ORGANZIED CRIME you will ever >> come across. Most people were afraid to speak out against them until this >> recent ground swell. >> >> This is the MALWARE CARTEL. GET THE PICTURE? >> >> Many links have been posted here that prove this already -- instead of >> asking >> what customers they cut off, let them show WHAT CUSTOMERS ARE LEGIT-- >> because there are NONE. >> >> >> >> >> >> > >> I would suggest a different Step 1. Instead of killing power, simply >> > >> isolate the affected machine. This might be as simple as putting up a >> > >> firewall rule or two, if it is simply sending outgoing SMTP spam, or >> > > it's probably easiest (depending on the network gear of course) to >> > > just put the lan port into an isolated VLAN. It's not the 100% >> > > solution (some badness rm's itself once it loses connectivity to the >> > > internets) but it'd make things simpler for the client/LEA when they >> > > need to figure out what happened. >> > > >> > > -chris >> > > >> > > >> > >> > >> >> >> >> >> > > > > > > From pauldotwall at gmail.com Wed Sep 24 03:19:16 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Wed, 24 Sep 2008 04:19:16 -0400 Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <1bbf3c240809240114rdd80e46p90dbe4da1a34e3fd@mail.gmail.com> References: <419009.17896.qm@web45010.mail.sp1.yahoo.com> <1bbf3c240809240114rdd80e46p90dbe4da1a34e3fd@mail.gmail.com> Message-ID: <620fd17c0809240119o755a1717jb7492285e4763953@mail.gmail.com> Russell, Thanks to the efforts of the people on this list, you've known Estdomains/Esthost was bad news for several weeks or more. Why are you only now shutting them down? Thank you for proving that our research was not for naught, and that Atrivo/Intercage is a black hat operation which needs to be permanently disconnected from the Internet at all costs. Drive Slow, Paul Wall From russm2k8 at yahoo.com Wed Sep 24 03:29:03 2008 From: russm2k8 at yahoo.com (Russell Mitchell) Date: Wed, 24 Sep 2008 01:29:03 -0700 (PDT) Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer Message-ID: <648989.85024.qm@web45013.mail.sp1.yahoo.com> Hello Mark, What's YOUR motivation to consistantly attack my company? What's my motivation to continue working @ InterCage? To keep a roof over?my family's heads, and to keep them well-fed: 1.) Myself 2.) My Wife 3.) My near 2 year old?Son (November) 4.) My near 3 week old Daughter (Born Sept. 4th) It's great that you finally accepted the claim of InterCage being associated with the famed "RBN" as being "alledged". You've taken the first step into seeing how much BS information has been spread out about our company. Whether you support me in my anti-abuse endeavor or not, as long as you get FACTUAL information, I'm happy. However someday, I trust you will find and accept the truth about InterCage. From what I see now from the claims your making, that day may not come soon. Thank you for your time. Have?a great day. ?--- Russell Mitchell InterCage, Inc. ----- Original Message ---- From: Mark Foo To: Russell Mitchell Cc: Bruce Williams ; Christopher Morrow ; nanog at nanog.org; Joe Greco Sent: Wednesday, September 24, 2008 1:14:01 AM Subject: Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer Russell: Oh I got the memo, you'll be getting served one soon too. I just wonder why you don't consider playing both sides of the fence -- with your knowledge of who's who in the cyber crime field, you could probably get paid more as an informant (either to LEO or one of the "Intel" companies than whatever you're doing for Emil and (allegedly) the? RBN. You can't possible sleep well knowing what your up to now so I figure it's the money that motivates you. Or, maybe you don't really know anyone, you just respond to their demands and they end up with all the money, pr0n chicks, etc. Doesn't that bother you -- don't you want more? Plus, no one would know you were pulling two pay checks -- you manage systems on one side and pass info to the other. It's actually fairly simple -- maybe you already know this ;). If not, please explain this: http://www.spamhaus.org/news.lasso?article=636 Without exception, all of the major security organizations on the Internet agree that the 'Home' of cybercrime in the western world is a firm known as Atrivo/Intercage, based in California. We ourselves have not come to this conclusion lightly but from many years of dealing with criminal operations hosted by Atrivo/Intercage, gangs of cybercriminals - mostly Russian and East European but with several US online crime gangs as well - whose activities always lead back to servers run by Atrivo/Intercage. We have lost count of the times we have tracked a major virus botnet's "command and control" to Atrivo/Intercage servers, readers can view here some of the current and historic SBL records for Atrivo for a taste of what has been happening in this network. At almost every Internet security conference, or law enforcement seminar on cyber-crime, a presentation will detail some attack, exploit, phish or financial crime that has some nexus at Atrivo/Intercage. The person who runs Atrivo/Intercage, Emil Kacperski is an expert at playing the "surprised janitor", unaware of every new criminal enterprise found on his servers and keen to show he gets rid of some criminals once their activities on his network are exposed. His Internet hosting career first came to the attention of most anti-abuse organizations when he pinched (or 'purchased stolen goods' as he put it) and routed an unused block of 65,536 IP addresses belonging to the County of Los Angeles. Spamhaus has dealt with over 350 incidents of cyber-crime hosting on Atrivo/Intercage and its related networks in the last 3 years alone, all of which involved criminal operations such as malware, virus spreaders and botnet command and control servers. Malware found by Spamhaus on Atrivo/Intercage/Cernel/Hostfresh just in the last few months included the Storm Worm installer and controller and a MySpace spambot amongst others. Spamhaus currently sees a large amount of activity related to malicious software and exploits being hosted on Atrivo/Intercage which include DNS hijack malware, IFRAME browser attacks, dialers, pirated software websites and blatantly criminal services. We assume that every law enforcement agency with a cyber-crimes division has a dossier bursting at the seams on Atrivo/Intercage and its tentacles such as Esthost, Estdomains, Cernel, Hostfresh. The only question on everyone's mind is which agency will beat the others to shutting the whole place down and indicting the people behind it. Because if shut down, one thing is certain: the amount of malware-driven crime on the Internet would drop overnight as cyber-criminals rush to find a new crime-friendly host - difficult to find in the US, as Atrivo/Intercage is one of the very few remaining dedicated crime hosting firms whose customer base is composed almost, or perhaps entirely, of criminal gangs. More importantly, millions of Internet users currently being targeted by the malware gangs operating from Atrivo/Intercage will be, for a while, safer. Perhaps one may be wondering about the costs of hosting at Atrivo/Intercage or how to sign up? Well, don't expect to find this information at the company's websites as they were empty for years and for the last year have just shown "Website Coming Soon." ? ? http://www.atrivo.com => "InterCage, Inc.. INTENSE SERVERS. Website Coming Soon:" ? ? Last Updated: Thursday, September 06, 2007 4:32:59 PM ? ? http://www.intercage.com => "InterCage, Inc. INTENSE SERVERS. Website Coming Soon:" ? ? Tuesday, September 04, 2007 6:45:52 PM At one time after being asked, "how on earth does your company get business?" an Atrivo/Intercage representative coyly said, "by word of mouth." That seems to be quite obvious. On Wed, Sep 24, 2008 at 12:45 AM, Russell Mitchell wrote: > Hello Mark, > > It really seems YOU _DID_ miss the memo. > I think that since no one else is responding to your non-sense, there is no reason for me to either. > > If you have something accurate to say, I'll be happy to listen. > Until then, there's not much I can say. There's no sense in repeating myself. >? --- > Russell Mitchell > > InterCage, Inc. > > > > ----- Original Message ---- > From: Mark Foo > To: Russell Mitchell > Cc: Bruce Williams ; Christopher Morrow ; nanog at nanog.org; Joe Greco > Sent: Wednesday, September 24, 2008 12:27:50 AM > Subject: Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer > > Russell: > > Ferg was just being coy -- what you don't understand is there are about 3 other > security mailing lists plotting to TAKE YOUR SERVICE DOWN. You FAIL. Law > Enforcement might not take action against you (but appear to be interested now), > but the community can. GET OFF THE NET WITH YOUR MALWARE! > > You mistake me for someone who believes you pack of lies! Don't you > understand each > time you post to this list gives those of us who know the opportunity > to post MORE EVIDENCE > of your MALWARE? > > You disconnected Hostfresh and think that's the extent of your cimes? > Gimme a break. > Only those who are easily socially engineered would believe your > pathetic claims of innocence. > You've BEEN HOSTING MALWARE since 2003 -- SEE Nanog post: > > Re: The in-your-face hijacking example > http://www.irbs.net/internet/nanog/0305/0038.html > >> Let me know if there's anything else you'd like me to state to the public. > > Answer Ferg's question -- Why are you moving to CERNAL? Do you think this > is going to work? That's just another of Emil's networks. > >> We're on a rocky road right now. But it IS starting to smooth out. > > That's just the calm before the storm. > > Go ahead and post a response to each of these allegations: > > Cybercrime's US Hosts > http://www.spamhaus.org/news.lasso?article=636 > > Report Slams U.S. Host as Major Source of Badware > http://voices.washingtonpost.com/securityfix/2008/08/report_slams_us_host_as_major.html?nav=rss_blog > > A Superlative Scam and Spam Site Registrar > http://voices.washingtonpost.com/securityfix/2008/09/estdomains.html?nav=rss_blog > > ICANN cast as online scam enabler > http://www.theregister.co.uk/2008/09/03/cyber_crime_reports/ > > 'Malware-friendly' Intercage back with the living > http://www.theregister..co.uk/2008/09/24/intercage_back_online/ > > > > > > > > > On Tue, Sep 23, 2008 at 11:50 PM, Russell Mitchell wrote: >> >> Hello John Doe, >> >> I welcome any further comments you have. >> We have to get past people such as yourself, and your blasphemous and false statements. >> >> This is the same issue with the recent media and self-proclaimed "Security Researchers". Fly-by-night mind you. >> >> To help you out in your claims: >> Yes, we did house a client whom had quite a run with their client's from various locations, such as Russia. >> That Client is no longer hosted on our network. I myself spent all of monday afternoon, night, and tuesday morning shutting off EVERY machine they had leased in our Billing System. I'm currently working to scan further and see if there's anything I may have missed. >> >> Yes, Russia is very well known for Virus and Malware writer's. >> >> Yes, we have had issues with malware distribution from our network. >> This was directly and near singularly related to the former client of ours. We did have another client, Hostfresh, whom had their share of malware issues. >> >> Both have been completely and effectively removed. The server's leased to both of them have been canceled, and their machines have been shutoff. >> >> Let me know if there's anything else you'd like me to state to the public. >> We're on a rocky road right now. But it IS starting to smooth out. >> >> Thank you for your time. Have a great day. >>? --- >> Russell Mitchell >> >> InterCage, Inc. >> >> >> >> ----- Original Message ---- >> From: Mark Foo >> To: Bruce Williams >> Cc: Christopher Morrow ; nanog at nanog.org; Joe Greco >> Sent: Tuesday, September 23, 2008 11:08:21 PM >> Subject: Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer >> >> NANOG: >> >> Look, the people posting here who are trashing Intercage are pure security >> analysts -- they >> know and understand the evil that is Intercage. STOP TRYING TO ASSIST >> INTERCAGE >> -- you are effectively aiding and abetting the enemy. >> >> Intercage/Atrivo hosts the malware c&c botnets that DDoS your systems and >> networks. >> >> Intercage/Atrivo hosts the spyware that compromises your users' passwords. >> >> Intercage/Atrivo hosts the adware that slows your customers' machines. >> >> Don't take my word for it, DO YOUR OWN RESEARCH: >> http://www.google.com/search?hl=en&q=intercage+malware >> >> You don't get called the ***American RBN*** for hosting a couple bad >> machines. They >> have and will continue to host much of the malware pumped out of America. >> THEY >> ARE NOT YOUR COMRADES.. >> >> These people represent the most HIGHLY ORGANZIED CRIME you will ever >> come across. Most people were afraid to speak out against them until this >> recent ground swell. >> >> This is the MALWARE CARTEL. GET THE PICTURE? >> >> Many links have been posted here that prove this already -- instead of >> asking >> what customers they cut off, let them show WHAT CUSTOMERS ARE LEGIT-- >> because there are NONE. >> >> >> >> >> >> > >> I would suggest a different Step 1.? Instead of killing power, simply >> > >> isolate the affected machine.? This might be as simple as putting up a >> > >> firewall rule or two, if it is simply sending outgoing SMTP spam, or >> > > it's probably easiest (depending on the network gear of course) to >> > > just put the lan port into an isolated VLAN. It's not the 100% >> > > solution (some badness rm's itself once it loses connectivity to the >> > > internets) but it'd make things simpler for the client/LEA when they >> > > need to figure out what happened. >> > > >> > > -chris >> > > >> > > >> > >> > >> >> >> >> >> > > > > > > From raymond at prolocation.net Wed Sep 24 03:33:35 2008 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Wed, 24 Sep 2008 10:33:35 +0200 (CEST) Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <620fd17c0809240119o755a1717jb7492285e4763953@mail.gmail.com> References: <419009.17896.qm@web45010.mail.sp1.yahoo.com> <1bbf3c240809240114rdd80e46p90dbe4da1a34e3fd@mail.gmail.com> <620fd17c0809240119o755a1717jb7492285e4763953@mail.gmail.com> Message-ID: Hi! > Thanks to the efforts of the people on this list, you've known > Estdomains/Esthost was bad news for several weeks or more. [root at control ~]# dig estdomains.com ; <<>> DiG 9.5.0-P2 <<>> estdomains.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2970 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;estdomains.com. IN A ;; ANSWER SECTION: estdomains.com. 86400 IN A 94.102.49.3 inetnum: 94.102.48.0 - 94.102.63.255 netname: NL-ECATEL-20080829 descr: Ecatel LTD country: NL org: ORG-EL38-RIPE admin-c: RvE16-RIPE tech-c: RvE16-RIPE status: ALLOCATED PA mnt-by: RIPE-NCC-HM-MNT mnt-lower: ECATEL-MNT mnt-routes: ECATEL-MNT source: RIPE # Filtered person: Reinier van Eeden address: Archangelkade 1-3 address: 1013 BE Amsterdam mnt-by: IQARUS-MNT e-mail: r.eeden at nl.iqarus.com phone: +31 64 607 11 12 nic-hdl: RvE16-RIPE source: RIPE # Filtered The same guys were hosting several ROKSO spammers in 2006 allready. This smells badly! Earlier this year they had also this one (also ROKSO) http://www.spamhaus.org/sbl/sbl.lasso?query=SBL65783 The company that Reinier was with was called Icarus earlier, does that ring a bell? 3 of the top 10 ROKSO spammers were hosted there. This is more then just a normal shining. bye, Raymond. From pmessri at gmail.com Wed Sep 24 03:35:50 2008 From: pmessri at gmail.com (Pedram M) Date: Wed, 24 Sep 2008 01:35:50 -0700 Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <648989.85024.qm@web45013.mail.sp1.yahoo.com> References: <648989.85024.qm@web45013.mail.sp1.yahoo.com> Message-ID: <9c9aa5d00809240135i30735d91ge0c7f47cf38e8dfb@mail.gmail.com> define:nanog North American Network Operators Group A membership organization that provides for the exchange of tecnical information among public, commercial ... I think this conversation should have ended way long time ago. My $0.50 cents + $1.00 or $2 Regards, Pedram On Wed, Sep 24, 2008 at 1:29 AM, Russell Mitchell wrote: > Hello Mark, > > What's YOUR motivation to consistantly attack my company? > > What's my motivation to continue working @ InterCage? > To keep a roof over my family's heads, and to keep them well-fed: > 1.) Myself > 2.) My Wife > 3.) My near 2 year old Son (November) > 4.) My near 3 week old Daughter (Born Sept. 4th) > > It's great that you finally accepted the claim of InterCage being > associated with the famed "RBN" as being "alledged". > You've taken the first step into seeing how much BS information has been > spread out about our company. > > Whether you support me in my anti-abuse endeavor or not, as long as you get > FACTUAL information, I'm happy. > However someday, I trust you will find and accept the truth about > InterCage. From what I see now from the claims your making, that day may not > come soon. > > Thank you for your time. Have a great day. > --- > Russell Mitchell > > InterCage, Inc. > > ----- Original Message ---- > From: Mark Foo > To: Russell Mitchell > Cc: Bruce Williams ; Christopher Morrow < > christopher.morrow at gmail.com>; nanog at nanog.org; Joe Greco < > jgreco at ns.sol.net> > Sent: Wednesday, September 24, 2008 1:14:01 AM > Subject: Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer > > Russell: > > Oh I got the memo, you'll be getting served one soon too. > > I just wonder why you don't consider playing both sides of the fence > -- with your > knowledge of who's who in the cyber crime field, you could probably get > paid > more as an informant (either to LEO or one of the "Intel" companies than > whatever you're doing for Emil and (allegedly) the RBN. You can't possible > sleep well knowing what your up to now so I figure it's the money that > motivates you. > > Or, maybe you don't really know anyone, you just respond to their demands > and > they end up with all the money, pr0n chicks, etc. Doesn't that bother > you -- don't > you want more? > > Plus, no one would know you were pulling two pay checks -- you manage > systems > on one side and pass info to the other. It's actually fairly simple -- > maybe you already > know this ;). > > If not, please explain this: > > http://www.spamhaus.org/news.lasso?article=636 > > Without exception, all of the major security organizations on the > Internet agree that the 'Home' of cybercrime in the western world is a > firm known as Atrivo/Intercage, based in California. We ourselves have > not come to this conclusion lightly but from many years of dealing > with criminal operations hosted by Atrivo/Intercage, gangs of > cybercriminals - mostly Russian and East European but with several US > online crime gangs as well - whose activities always lead back to > servers run by Atrivo/Intercage. We have lost count of the times we > have tracked a major virus botnet's "command and control" to > Atrivo/Intercage servers, readers can view here some of the current > and historic SBL records for Atrivo for a taste of what has been > happening in this network. At almost every Internet security > conference, or law enforcement seminar on cyber-crime, a presentation > will detail some attack, exploit, phish or financial crime that has > some nexus at Atrivo/Intercage. > > The person who runs Atrivo/Intercage, Emil Kacperski is an expert at > playing the "surprised janitor", unaware of every new criminal > enterprise found on his servers and keen to show he gets rid of some > criminals once their activities on his network are exposed. His > Internet hosting career first came to the attention of most anti-abuse > organizations when he pinched (or 'purchased stolen goods' as he put > it) and routed an unused block of 65,536 IP addresses belonging to the > County of Los Angeles. > > Spamhaus has dealt with over 350 incidents of cyber-crime hosting on > Atrivo/Intercage and its related networks in the last 3 years alone, > all of which involved criminal operations such as malware, virus > spreaders and botnet command and control servers. Malware found by > Spamhaus on Atrivo/Intercage/Cernel/Hostfresh just in the last few > months included the Storm Worm installer and controller and a MySpace > spambot amongst others. Spamhaus currently sees a large amount of > activity related to malicious software and exploits being hosted on > Atrivo/Intercage which include DNS hijack malware, IFRAME browser > attacks, dialers, pirated software websites and blatantly criminal > services. > > We assume that every law enforcement agency with a cyber-crimes > division has a dossier bursting at the seams on Atrivo/Intercage and > its tentacles such as Esthost, Estdomains, Cernel, Hostfresh. The only > question on everyone's mind is which agency will beat the others to > shutting the whole place down and indicting the people behind it. > Because if shut down, one thing is certain: the amount of > malware-driven crime on the Internet would drop overnight as > cyber-criminals rush to find a new crime-friendly host - difficult to > find in the US, as Atrivo/Intercage is one of the very few remaining > dedicated crime hosting firms whose customer base is composed almost, > or perhaps entirely, of criminal gangs. More importantly, millions of > Internet users currently being targeted by the malware gangs operating > from Atrivo/Intercage will be, for a while, safer. > > Perhaps one may be wondering about the costs of hosting at > Atrivo/Intercage or how to sign up? Well, don't expect to find this > information at the company's websites as they were empty for years and > for the last year have just shown "Website Coming Soon." > > http://www.atrivo.com => "InterCage, Inc.. INTENSE SERVERS. Website > Coming Soon:" > Last Updated: Thursday, September 06, 2007 4:32:59 PM > > http://www.intercage.com => "InterCage, Inc. INTENSE SERVERS. > Website Coming Soon:" > Tuesday, September 04, 2007 6:45:52 PM > > At one time after being asked, "how on earth does your company get > business?" an Atrivo/Intercage representative coyly said, "by word of > mouth." That seems to be quite obvious. > > > > > On Wed, Sep 24, 2008 at 12:45 AM, Russell Mitchell > wrote: > > Hello Mark, > > > > It really seems YOU _DID_ miss the memo. > > I think that since no one else is responding to your non-sense, there is > no reason for me to either. > > > > If you have something accurate to say, I'll be happy to listen. > > Until then, there's not much I can say. There's no sense in repeating > myself. > > --- > > Russell Mitchell > > > > InterCage, Inc. > > > > > > > > ----- Original Message ---- > > From: Mark Foo > > To: Russell Mitchell > > Cc: Bruce Williams ; Christopher Morrow < > christopher.morrow at gmail.com>; nanog at nanog.org; Joe Greco < > jgreco at ns.sol.net> > > Sent: Wednesday, September 24, 2008 12:27:50 AM > > Subject: Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer > > > > Russell: > > > > Ferg was just being coy -- what you don't understand is there are about 3 > other > > security mailing lists plotting to TAKE YOUR SERVICE DOWN. You FAIL. Law > > Enforcement might not take action against you (but appear to be > interested now), > > but the community can. GET OFF THE NET WITH YOUR MALWARE! > > > > You mistake me for someone who believes you pack of lies! Don't you > > understand each > > time you post to this list gives those of us who know the opportunity > > to post MORE EVIDENCE > > of your MALWARE? > > > > You disconnected Hostfresh and think that's the extent of your cimes? > > Gimme a break. > > Only those who are easily socially engineered would believe your > > pathetic claims of innocence. > > You've BEEN HOSTING MALWARE since 2003 -- SEE Nanog post: > > > > Re: The in-your-face hijacking example > > http://www.irbs.net/internet/nanog/0305/0038.html > > > >> Let me know if there's anything else you'd like me to state to the > public. > > > > Answer Ferg's question -- Why are you moving to CERNAL? Do you think this > > is going to work? That's just another of Emil's networks. > > > >> We're on a rocky road right now. But it IS starting to smooth out. > > > > That's just the calm before the storm. > > > > Go ahead and post a response to each of these allegations: > > > > Cybercrime's US Hosts > > http://www.spamhaus.org/news.lasso?article=636 > > > > Report Slams U.S. Host as Major Source of Badware > > > http://voices.washingtonpost.com/securityfix/2008/08/report_slams_us_host_as_major.html?nav=rss_blog > > > > A Superlative Scam and Spam Site Registrar > > > http://voices.washingtonpost.com/securityfix/2008/09/estdomains.html?nav=rss_blog > > > > ICANN cast as online scam enabler > > http://www.theregister.co.uk/2008/09/03/cyber_crime_reports/ > > > > 'Malware-friendly' Intercage back with the living > > http://www.theregister..co.uk/2008/09/24/intercage_back_online/ > > > > > > > > > > > > > > > > > > On Tue, Sep 23, 2008 at 11:50 PM, Russell Mitchell > wrote: > >> > >> Hello John Doe, > >> > >> I welcome any further comments you have. > >> We have to get past people such as yourself, and your blasphemous and > false statements. > >> > >> This is the same issue with the recent media and self-proclaimed > "Security Researchers". Fly-by-night mind you. > >> > >> To help you out in your claims: > >> Yes, we did house a client whom had quite a run with their client's from > various locations, such as Russia. > >> That Client is no longer hosted on our network. I myself spent all of > monday afternoon, night, and tuesday morning shutting off EVERY machine they > had leased in our Billing System. I'm currently working to scan further and > see if there's anything I may have missed. > >> > >> Yes, Russia is very well known for Virus and Malware writer's. > >> > >> Yes, we have had issues with malware distribution from our network. > >> This was directly and near singularly related to the former client of > ours. We did have another client, Hostfresh, whom had their share of malware > issues. > >> > >> Both have been completely and effectively removed. The server's leased > to both of them have been canceled, and their machines have been shutoff. > >> > >> Let me know if there's anything else you'd like me to state to the > public. > >> We're on a rocky road right now. But it IS starting to smooth out. > >> > >> Thank you for your time. Have a great day. > >> --- > >> Russell Mitchell > >> > >> InterCage, Inc. > >> > >> > >> > >> ----- Original Message ---- > >> From: Mark Foo > >> To: Bruce Williams > >> Cc: Christopher Morrow ; nanog at nanog.org; > Joe Greco > >> Sent: Tuesday, September 23, 2008 11:08:21 PM > >> Subject: Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer > >> > >> NANOG: > >> > >> Look, the people posting here who are trashing Intercage are pure > security > >> analysts -- they > >> know and understand the evil that is Intercage. STOP TRYING TO ASSIST > >> INTERCAGE > >> -- you are effectively aiding and abetting the enemy. > >> > >> Intercage/Atrivo hosts the malware c&c botnets that DDoS your systems > and > >> networks. > >> > >> Intercage/Atrivo hosts the spyware that compromises your users' > passwords. > >> > >> Intercage/Atrivo hosts the adware that slows your customers' machines. > >> > >> Don't take my word for it, DO YOUR OWN RESEARCH: > >> http://www.google.com/search?hl=en&q=intercage+malware > >> > >> You don't get called the ***American RBN*** for hosting a couple bad > >> machines. They > >> have and will continue to host much of the malware pumped out of > America. > >> THEY > >> ARE NOT YOUR COMRADES.. > >> > >> These people represent the most HIGHLY ORGANZIED CRIME you will ever > >> come across. Most people were afraid to speak out against them until > this > >> recent ground swell. > >> > >> This is the MALWARE CARTEL. GET THE PICTURE? > >> > >> Many links have been posted here that prove this already -- instead of > >> asking > >> what customers they cut off, let them show WHAT CUSTOMERS ARE LEGIT-- > >> because there are NONE. > >> > >> > >> > >> > >> > >> > >> I would suggest a different Step 1. Instead of killing power, > simply > >> > >> isolate the affected machine. This might be as simple as putting > up a > >> > >> firewall rule or two, if it is simply sending outgoing SMTP spam, > or > >> > > it's probably easiest (depending on the network gear of course) to > >> > > just put the lan port into an isolated VLAN. It's not the 100% > >> > > solution (some badness rm's itself once it loses connectivity to the > >> > > internets) but it'd make things simpler for the client/LEA when they > >> > > need to figure out what happened. > >> > > > >> > > -chris > >> > > > >> > > > >> > > >> > > >> > >> > >> > >> > >> > > > > > > > > > > > > > > > > > > > From pmessri at gmail.com Wed Sep 24 03:36:48 2008 From: pmessri at gmail.com (Pedram M) Date: Wed, 24 Sep 2008 01:36:48 -0700 Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <9c9aa5d00809240135i30735d91ge0c7f47cf38e8dfb@mail.gmail.com> References: <648989.85024.qm@web45013.mail.sp1.yahoo.com> <9c9aa5d00809240135i30735d91ge0c7f47cf38e8dfb@mail.gmail.com> Message-ID: <9c9aa5d00809240136j31ae172fs2f3f0cf70e5a0b4b@mail.gmail.com> It's actually starting to look like WHT. On Wed, Sep 24, 2008 at 1:35 AM, Pedram M wrote: > > define:nanog > > North American Network Operators Group A membership organization that > provides for the exchange of tecnical information among public, commercial > ... > > I think this conversation should have ended way long time ago. > > My $0.50 cents + $1.00 or $2 > > Regards, > Pedram > > > On Wed, Sep 24, 2008 at 1:29 AM, Russell Mitchell wrote: > >> Hello Mark, >> >> What's YOUR motivation to consistantly attack my company? >> >> What's my motivation to continue working @ InterCage? >> To keep a roof over my family's heads, and to keep them well-fed: >> 1.) Myself >> 2.) My Wife >> 3.) My near 2 year old Son (November) >> 4.) My near 3 week old Daughter (Born Sept. 4th) >> >> It's great that you finally accepted the claim of InterCage being >> associated with the famed "RBN" as being "alledged". >> You've taken the first step into seeing how much BS information has been >> spread out about our company. >> >> Whether you support me in my anti-abuse endeavor or not, as long as you >> get FACTUAL information, I'm happy. >> However someday, I trust you will find and accept the truth about >> InterCage. From what I see now from the claims your making, that day may not >> come soon. >> >> Thank you for your time. Have a great day. >> --- >> Russell Mitchell >> >> InterCage, Inc. >> >> ----- Original Message ---- >> From: Mark Foo >> To: Russell Mitchell >> Cc: Bruce Williams ; Christopher Morrow < >> christopher.morrow at gmail.com>; nanog at nanog.org; Joe Greco < >> jgreco at ns.sol.net> >> Sent: Wednesday, September 24, 2008 1:14:01 AM >> Subject: Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer >> >> Russell: >> >> Oh I got the memo, you'll be getting served one soon too. >> >> I just wonder why you don't consider playing both sides of the fence >> -- with your >> knowledge of who's who in the cyber crime field, you could probably get >> paid >> more as an informant (either to LEO or one of the "Intel" companies than >> whatever you're doing for Emil and (allegedly) the RBN. You can't >> possible >> sleep well knowing what your up to now so I figure it's the money that >> motivates you. >> >> Or, maybe you don't really know anyone, you just respond to their demands >> and >> they end up with all the money, pr0n chicks, etc. Doesn't that bother >> you -- don't >> you want more? >> >> Plus, no one would know you were pulling two pay checks -- you manage >> systems >> on one side and pass info to the other. It's actually fairly simple -- >> maybe you already >> know this ;). >> >> If not, please explain this: >> >> http://www.spamhaus.org/news.lasso?article=636 >> >> Without exception, all of the major security organizations on the >> Internet agree that the 'Home' of cybercrime in the western world is a >> firm known as Atrivo/Intercage, based in California. We ourselves have >> not come to this conclusion lightly but from many years of dealing >> with criminal operations hosted by Atrivo/Intercage, gangs of >> cybercriminals - mostly Russian and East European but with several US >> online crime gangs as well - whose activities always lead back to >> servers run by Atrivo/Intercage. We have lost count of the times we >> have tracked a major virus botnet's "command and control" to >> Atrivo/Intercage servers, readers can view here some of the current >> and historic SBL records for Atrivo for a taste of what has been >> happening in this network. At almost every Internet security >> conference, or law enforcement seminar on cyber-crime, a presentation >> will detail some attack, exploit, phish or financial crime that has >> some nexus at Atrivo/Intercage. >> >> The person who runs Atrivo/Intercage, Emil Kacperski is an expert at >> playing the "surprised janitor", unaware of every new criminal >> enterprise found on his servers and keen to show he gets rid of some >> criminals once their activities on his network are exposed. His >> Internet hosting career first came to the attention of most anti-abuse >> organizations when he pinched (or 'purchased stolen goods' as he put >> it) and routed an unused block of 65,536 IP addresses belonging to the >> County of Los Angeles. >> >> Spamhaus has dealt with over 350 incidents of cyber-crime hosting on >> Atrivo/Intercage and its related networks in the last 3 years alone, >> all of which involved criminal operations such as malware, virus >> spreaders and botnet command and control servers. Malware found by >> Spamhaus on Atrivo/Intercage/Cernel/Hostfresh just in the last few >> months included the Storm Worm installer and controller and a MySpace >> spambot amongst others. Spamhaus currently sees a large amount of >> activity related to malicious software and exploits being hosted on >> Atrivo/Intercage which include DNS hijack malware, IFRAME browser >> attacks, dialers, pirated software websites and blatantly criminal >> services. >> >> We assume that every law enforcement agency with a cyber-crimes >> division has a dossier bursting at the seams on Atrivo/Intercage and >> its tentacles such as Esthost, Estdomains, Cernel, Hostfresh. The only >> question on everyone's mind is which agency will beat the others to >> shutting the whole place down and indicting the people behind it. >> Because if shut down, one thing is certain: the amount of >> malware-driven crime on the Internet would drop overnight as >> cyber-criminals rush to find a new crime-friendly host - difficult to >> find in the US, as Atrivo/Intercage is one of the very few remaining >> dedicated crime hosting firms whose customer base is composed almost, >> or perhaps entirely, of criminal gangs. More importantly, millions of >> Internet users currently being targeted by the malware gangs operating >> from Atrivo/Intercage will be, for a while, safer. >> >> Perhaps one may be wondering about the costs of hosting at >> Atrivo/Intercage or how to sign up? Well, don't expect to find this >> information at the company's websites as they were empty for years and >> for the last year have just shown "Website Coming Soon." >> >> http://www.atrivo.com => "InterCage, Inc.. INTENSE SERVERS. Website >> Coming Soon:" >> Last Updated: Thursday, September 06, 2007 4:32:59 PM >> >> http://www.intercage.com => "InterCage, Inc. INTENSE SERVERS. >> Website Coming Soon:" >> Tuesday, September 04, 2007 6:45:52 PM >> >> At one time after being asked, "how on earth does your company get >> business?" an Atrivo/Intercage representative coyly said, "by word of >> mouth." That seems to be quite obvious. >> >> >> >> >> On Wed, Sep 24, 2008 at 12:45 AM, Russell Mitchell >> wrote: >> > Hello Mark, >> > >> > It really seems YOU _DID_ miss the memo. >> > I think that since no one else is responding to your non-sense, there is >> no reason for me to either. >> > >> > If you have something accurate to say, I'll be happy to listen. >> > Until then, there's not much I can say. There's no sense in repeating >> myself. >> > --- >> > Russell Mitchell >> > >> > InterCage, Inc. >> > >> > >> > >> > ----- Original Message ---- >> > From: Mark Foo >> > To: Russell Mitchell >> > Cc: Bruce Williams ; Christopher Morrow < >> christopher.morrow at gmail.com>; nanog at nanog.org; Joe Greco < >> jgreco at ns.sol.net> >> > Sent: Wednesday, September 24, 2008 12:27:50 AM >> > Subject: Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer >> > >> > Russell: >> > >> > Ferg was just being coy -- what you don't understand is there are about >> 3 other >> > security mailing lists plotting to TAKE YOUR SERVICE DOWN. You FAIL. Law >> > Enforcement might not take action against you (but appear to be >> interested now), >> > but the community can. GET OFF THE NET WITH YOUR MALWARE! >> > >> > You mistake me for someone who believes you pack of lies! Don't you >> > understand each >> > time you post to this list gives those of us who know the opportunity >> > to post MORE EVIDENCE >> > of your MALWARE? >> > >> > You disconnected Hostfresh and think that's the extent of your cimes? >> > Gimme a break. >> > Only those who are easily socially engineered would believe your >> > pathetic claims of innocence. >> > You've BEEN HOSTING MALWARE since 2003 -- SEE Nanog post: >> > >> > Re: The in-your-face hijacking example >> > http://www.irbs.net/internet/nanog/0305/0038.html >> > >> >> Let me know if there's anything else you'd like me to state to the >> public. >> > >> > Answer Ferg's question -- Why are you moving to CERNAL? Do you think >> this >> > is going to work? That's just another of Emil's networks. >> > >> >> We're on a rocky road right now. But it IS starting to smooth out. >> > >> > That's just the calm before the storm. >> > >> > Go ahead and post a response to each of these allegations: >> > >> > Cybercrime's US Hosts >> > http://www.spamhaus.org/news.lasso?article=636 >> > >> > Report Slams U.S. Host as Major Source of Badware >> > >> http://voices.washingtonpost.com/securityfix/2008/08/report_slams_us_host_as_major.html?nav=rss_blog >> > >> > A Superlative Scam and Spam Site Registrar >> > >> http://voices.washingtonpost.com/securityfix/2008/09/estdomains.html?nav=rss_blog >> > >> > ICANN cast as online scam enabler >> > http://www.theregister.co.uk/2008/09/03/cyber_crime_reports/ >> > >> > 'Malware-friendly' Intercage back with the living >> > http://www.theregister..co.uk/2008/09/24/intercage_back_online/ >> > >> > >> > >> > >> > >> > >> > >> > >> > On Tue, Sep 23, 2008 at 11:50 PM, Russell Mitchell >> wrote: >> >> >> >> Hello John Doe, >> >> >> >> I welcome any further comments you have. >> >> We have to get past people such as yourself, and your blasphemous and >> false statements. >> >> >> >> This is the same issue with the recent media and self-proclaimed >> "Security Researchers". Fly-by-night mind you. >> >> >> >> To help you out in your claims: >> >> Yes, we did house a client whom had quite a run with their client's >> from various locations, such as Russia. >> >> That Client is no longer hosted on our network. I myself spent all of >> monday afternoon, night, and tuesday morning shutting off EVERY machine they >> had leased in our Billing System. I'm currently working to scan further and >> see if there's anything I may have missed. >> >> >> >> Yes, Russia is very well known for Virus and Malware writer's. >> >> >> >> Yes, we have had issues with malware distribution from our network. >> >> This was directly and near singularly related to the former client of >> ours. We did have another client, Hostfresh, whom had their share of malware >> issues. >> >> >> >> Both have been completely and effectively removed. The server's leased >> to both of them have been canceled, and their machines have been shutoff. >> >> >> >> Let me know if there's anything else you'd like me to state to the >> public. >> >> We're on a rocky road right now. But it IS starting to smooth out. >> >> >> >> Thank you for your time. Have a great day. >> >> --- >> >> Russell Mitchell >> >> >> >> InterCage, Inc. >> >> >> >> >> >> >> >> ----- Original Message ---- >> >> From: Mark Foo >> >> To: Bruce Williams >> >> Cc: Christopher Morrow ; nanog at nanog.org; >> Joe Greco >> >> Sent: Tuesday, September 23, 2008 11:08:21 PM >> >> Subject: Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer >> >> >> >> NANOG: >> >> >> >> Look, the people posting here who are trashing Intercage are pure >> security >> >> analysts -- they >> >> know and understand the evil that is Intercage. STOP TRYING TO ASSIST >> >> INTERCAGE >> >> -- you are effectively aiding and abetting the enemy. >> >> >> >> Intercage/Atrivo hosts the malware c&c botnets that DDoS your systems >> and >> >> networks. >> >> >> >> Intercage/Atrivo hosts the spyware that compromises your users' >> passwords. >> >> >> >> Intercage/Atrivo hosts the adware that slows your customers' machines. >> >> >> >> Don't take my word for it, DO YOUR OWN RESEARCH: >> >> http://www.google.com/search?hl=en&q=intercage+malware >> >> >> >> You don't get called the ***American RBN*** for hosting a couple bad >> >> machines. They >> >> have and will continue to host much of the malware pumped out of >> America. >> >> THEY >> >> ARE NOT YOUR COMRADES.. >> >> >> >> These people represent the most HIGHLY ORGANZIED CRIME you will ever >> >> come across. Most people were afraid to speak out against them until >> this >> >> recent ground swell. >> >> >> >> This is the MALWARE CARTEL. GET THE PICTURE? >> >> >> >> Many links have been posted here that prove this already -- instead of >> >> asking >> >> what customers they cut off, let them show WHAT CUSTOMERS ARE LEGIT-- >> >> because there are NONE. >> >> >> >> >> >> >> >> >> >> >> >> > >> I would suggest a different Step 1. Instead of killing power, >> simply >> >> > >> isolate the affected machine. This might be as simple as putting >> up a >> >> > >> firewall rule or two, if it is simply sending outgoing SMTP spam, >> or >> >> > > it's probably easiest (depending on the network gear of course) to >> >> > > just put the lan port into an isolated VLAN. It's not the 100% >> >> > > solution (some badness rm's itself once it loses connectivity to >> the >> >> > > internets) but it'd make things simpler for the client/LEA when >> they >> >> > > need to figure out what happened. >> >> > > >> >> > > -chris >> >> > > >> >> > > >> >> > >> >> > >> >> >> >> >> >> >> >> >> >> >> > >> > >> > >> > >> > >> > >> >> >> >> >> >> >> > From michael.dillon at bt.com Wed Sep 24 04:23:01 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 24 Sep 2008 10:23:01 +0100 Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <6cd462c00809240038gc76350csc25e1c3d1cc87f1c@mail.gmail.com> Message-ID: > It is clear to me -- at least -- that this entire criminal > operation is being operated out of Eastern Europe, and their > foothold in the U.S. is the major issue here. If you believe that this is a criminal operation then you should keep this discussion OFF THE LIST and discourage anyone from taking any action against the bad guys that might disrupt evidence gathering. If this is a criminal matter, then it is best to keep quiet, collect good evidence, and go to court. Better to get a court injunction ordering them to stop sending malware, and then collect evidence showing that they violated the injunction. To do this, they need to have functioning upstream connections to your network. NANOG is not the place to discuss these things. None of this is network operational. The whole discussion amounts to a shouting match between vigilantes and their victims. Some of those victims might also be bad guys, but a shouting match on NANOG does not prove this one way or the other. --Michael Dillon From russm2k8 at yahoo.com Wed Sep 24 04:32:56 2008 From: russm2k8 at yahoo.com (Russell Mitchell) Date: Wed, 24 Sep 2008 02:32:56 -0700 (PDT) Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer Message-ID: <272934.76614.qm@web45014.mail.sp1.yahoo.com> Hello Michael, THANK YOU for the Intervention. If anyone would like to continue the chats,?drop me an email, and we can continue talks OFF NANOG. Thank you all very much for your time and careful consideration into the issues we're having. Have a great day. ?--- Russell Mitchell InterCage, Inc. ----- Original Message ---- From: "michael.dillon at bt.com" To: nanog at nanog.org Sent: Wednesday, September 24, 2008 2:23:01 AM Subject: RE: YAY! Re: Atrivo/Intercage: NO Upstream depeer > It is clear to me -- at least -- that this entire criminal > operation is being operated out of Eastern Europe, and their > foothold in the U.S. is the major issue here. If you believe that this is a criminal operation then you should keep this discussion OFF THE LIST and discourage anyone from taking any action against the bad guys that might disrupt evidence gathering. If this is a criminal matter, then it is best to keep quiet, collect good evidence, and go to court. Better to get a court injunction ordering them to stop sending malware, and then collect evidence showing that they violated the injunction. To do this, they need to have functioning upstream connections to your network. NANOG is not the place to discuss these things. None of this is network operational. The whole discussion amounts to a shouting match between vigilantes and their victims. Some of those victims might also be bad guys, but a shouting match on NANOG does not prove this one way or the other. --Michael Dillon From ge at linuxbox.org Wed Sep 24 05:51:38 2008 From: ge at linuxbox.org (Gadi Evron) Date: Wed, 24 Sep 2008 05:51:38 -0500 (CDT) Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <648989.85024.qm@web45013.mail.sp1.yahoo.com> References: <648989.85024.qm@web45013.mail.sp1.yahoo.com> Message-ID: On Wed, 24 Sep 2008, Russell Mitchell wrote: > Hello Mark, > > What's YOUR motivation to consistantly attack my company? I don't know this Mark, but it seems like he is copying your strategy of "stay up last and you win" as you both make little sense. Gadi. > What's my motivation to continue working @ InterCage? > To keep a roof over?my family's heads, and to keep them well-fed: > 1.) Myself > 2.) My Wife > 3.) My near 2 year old?Son (November) > 4.) My near 3 week old Daughter (Born Sept. 4th) > > It's great that you finally accepted the claim of InterCage being associated with the famed "RBN" as being "alledged". > You've taken the first step into seeing how much BS information has been spread out about our company. > > Whether you support me in my anti-abuse endeavor or not, as long as you get FACTUAL information, I'm happy. > However someday, I trust you will find and accept the truth about InterCage. From what I see now from the claims your making, that day may not come soon. > > Thank you for your time. Have?a great day. > ?--- > Russell Mitchell > > InterCage, Inc. > > ----- Original Message ---- > From: Mark Foo > To: Russell Mitchell > Cc: Bruce Williams ; Christopher Morrow ; nanog at nanog.org; Joe Greco > Sent: Wednesday, September 24, 2008 1:14:01 AM > Subject: Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer > > Russell: > > Oh I got the memo, you'll be getting served one soon too. > > I just wonder why you don't consider playing both sides of the fence > -- with your > knowledge of who's who in the cyber crime field, you could probably get paid > more as an informant (either to LEO or one of the "Intel" companies than > whatever you're doing for Emil and (allegedly) the? RBN. You can't possible > sleep well knowing what your up to now so I figure it's the money that > motivates you. > > Or, maybe you don't really know anyone, you just respond to their demands and > they end up with all the money, pr0n chicks, etc. Doesn't that bother > you -- don't > you want more? > > Plus, no one would know you were pulling two pay checks -- you manage systems > on one side and pass info to the other. It's actually fairly simple -- > maybe you already > know this ;). > > If not, please explain this: > > http://www.spamhaus.org/news.lasso?article=636 > > Without exception, all of the major security organizations on the > Internet agree that the 'Home' of cybercrime in the western world is a > firm known as Atrivo/Intercage, based in California. We ourselves have > not come to this conclusion lightly but from many years of dealing > with criminal operations hosted by Atrivo/Intercage, gangs of > cybercriminals - mostly Russian and East European but with several US > online crime gangs as well - whose activities always lead back to > servers run by Atrivo/Intercage. We have lost count of the times we > have tracked a major virus botnet's "command and control" to > Atrivo/Intercage servers, readers can view here some of the current > and historic SBL records for Atrivo for a taste of what has been > happening in this network. At almost every Internet security > conference, or law enforcement seminar on cyber-crime, a presentation > will detail some attack, exploit, phish or financial crime that has > some nexus at Atrivo/Intercage. > > The person who runs Atrivo/Intercage, Emil Kacperski is an expert at > playing the "surprised janitor", unaware of every new criminal > enterprise found on his servers and keen to show he gets rid of some > criminals once their activities on his network are exposed. His > Internet hosting career first came to the attention of most anti-abuse > organizations when he pinched (or 'purchased stolen goods' as he put > it) and routed an unused block of 65,536 IP addresses belonging to the > County of Los Angeles. > > Spamhaus has dealt with over 350 incidents of cyber-crime hosting on > Atrivo/Intercage and its related networks in the last 3 years alone, > all of which involved criminal operations such as malware, virus > spreaders and botnet command and control servers. Malware found by > Spamhaus on Atrivo/Intercage/Cernel/Hostfresh just in the last few > months included the Storm Worm installer and controller and a MySpace > spambot amongst others. Spamhaus currently sees a large amount of > activity related to malicious software and exploits being hosted on > Atrivo/Intercage which include DNS hijack malware, IFRAME browser > attacks, dialers, pirated software websites and blatantly criminal > services. > > We assume that every law enforcement agency with a cyber-crimes > division has a dossier bursting at the seams on Atrivo/Intercage and > its tentacles such as Esthost, Estdomains, Cernel, Hostfresh. The only > question on everyone's mind is which agency will beat the others to > shutting the whole place down and indicting the people behind it. > Because if shut down, one thing is certain: the amount of > malware-driven crime on the Internet would drop overnight as > cyber-criminals rush to find a new crime-friendly host - difficult to > find in the US, as Atrivo/Intercage is one of the very few remaining > dedicated crime hosting firms whose customer base is composed almost, > or perhaps entirely, of criminal gangs. More importantly, millions of > Internet users currently being targeted by the malware gangs operating > from Atrivo/Intercage will be, for a while, safer. > > Perhaps one may be wondering about the costs of hosting at > Atrivo/Intercage or how to sign up? Well, don't expect to find this > information at the company's websites as they were empty for years and > for the last year have just shown "Website Coming Soon." > > ? ? http://www.atrivo.com => "InterCage, Inc.. INTENSE SERVERS. Website > Coming Soon:" > ? ? Last Updated: Thursday, September 06, 2007 4:32:59 PM > > ? ? http://www.intercage.com => "InterCage, Inc. INTENSE SERVERS. > Website Coming Soon:" > ? ? Tuesday, September 04, 2007 6:45:52 PM > > At one time after being asked, "how on earth does your company get > business?" an Atrivo/Intercage representative coyly said, "by word of > mouth." That seems to be quite obvious. > > > > > On Wed, Sep 24, 2008 at 12:45 AM, Russell Mitchell wrote: >> Hello Mark, >> >> It really seems YOU _DID_ miss the memo. >> I think that since no one else is responding to your non-sense, there is no reason for me to either. >> >> If you have something accurate to say, I'll be happy to listen. >> Until then, there's not much I can say. There's no sense in repeating myself. >> ? --- >> Russell Mitchell >> >> InterCage, Inc. >> >> >> >> ----- Original Message ---- >> From: Mark Foo >> To: Russell Mitchell >> Cc: Bruce Williams ; Christopher Morrow ; nanog at nanog.org; Joe Greco >> Sent: Wednesday, September 24, 2008 12:27:50 AM >> Subject: Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer >> >> Russell: >> >> Ferg was just being coy -- what you don't understand is there are about 3 other >> security mailing lists plotting to TAKE YOUR SERVICE DOWN. You FAIL. Law >> Enforcement might not take action against you (but appear to be interested now), >> but the community can. GET OFF THE NET WITH YOUR MALWARE! >> >> You mistake me for someone who believes you pack of lies! Don't you >> understand each >> time you post to this list gives those of us who know the opportunity >> to post MORE EVIDENCE >> of your MALWARE? >> >> You disconnected Hostfresh and think that's the extent of your cimes? >> Gimme a break. >> Only those who are easily socially engineered would believe your >> pathetic claims of innocence. >> You've BEEN HOSTING MALWARE since 2003 -- SEE Nanog post: >> >> Re: The in-your-face hijacking example >> http://www.irbs.net/internet/nanog/0305/0038.html >> >>> Let me know if there's anything else you'd like me to state to the public. >> >> Answer Ferg's question -- Why are you moving to CERNAL? Do you think this >> is going to work? That's just another of Emil's networks. >> >>> We're on a rocky road right now. But it IS starting to smooth out. >> >> That's just the calm before the storm. >> >> Go ahead and post a response to each of these allegations: >> >> Cybercrime's US Hosts >> http://www.spamhaus.org/news.lasso?article=636 >> >> Report Slams U.S. Host as Major Source of Badware >> http://voices.washingtonpost.com/securityfix/2008/08/report_slams_us_host_as_major.html?nav=rss_blog >> >> A Superlative Scam and Spam Site Registrar >> http://voices.washingtonpost.com/securityfix/2008/09/estdomains.html?nav=rss_blog >> >> ICANN cast as online scam enabler >> http://www.theregister.co.uk/2008/09/03/cyber_crime_reports/ >> >> 'Malware-friendly' Intercage back with the living >> http://www.theregister..co.uk/2008/09/24/intercage_back_online/ >> >> >> >> >> >> >> >> >> On Tue, Sep 23, 2008 at 11:50 PM, Russell Mitchell wrote: >>> >>> Hello John Doe, >>> >>> I welcome any further comments you have. >>> We have to get past people such as yourself, and your blasphemous and false statements. >>> >>> This is the same issue with the recent media and self-proclaimed "Security Researchers". Fly-by-night mind you. >>> >>> To help you out in your claims: >>> Yes, we did house a client whom had quite a run with their client's from various locations, such as Russia. >>> That Client is no longer hosted on our network. I myself spent all of monday afternoon, night, and tuesday morning shutting off EVERY machine they had leased in our Billing System. I'm currently working to scan further and see if there's anything I may have missed. >>> >>> Yes, Russia is very well known for Virus and Malware writer's. >>> >>> Yes, we have had issues with malware distribution from our network. >>> This was directly and near singularly related to the former client of ours. We did have another client, Hostfresh, whom had their share of malware issues. >>> >>> Both have been completely and effectively removed. The server's leased to both of them have been canceled, and their machines have been shutoff. >>> >>> Let me know if there's anything else you'd like me to state to the public. >>> We're on a rocky road right now. But it IS starting to smooth out. >>> >>> Thank you for your time. Have a great day. >>> ? --- >>> Russell Mitchell >>> >>> InterCage, Inc. >>> >>> >>> >>> ----- Original Message ---- >>> From: Mark Foo >>> To: Bruce Williams >>> Cc: Christopher Morrow ; nanog at nanog.org; Joe Greco >>> Sent: Tuesday, September 23, 2008 11:08:21 PM >>> Subject: Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer >>> >>> NANOG: >>> >>> Look, the people posting here who are trashing Intercage are pure security >>> analysts -- they >>> know and understand the evil that is Intercage. STOP TRYING TO ASSIST >>> INTERCAGE >>> -- you are effectively aiding and abetting the enemy. >>> >>> Intercage/Atrivo hosts the malware c&c botnets that DDoS your systems and >>> networks. >>> >>> Intercage/Atrivo hosts the spyware that compromises your users' passwords. >>> >>> Intercage/Atrivo hosts the adware that slows your customers' machines. >>> >>> Don't take my word for it, DO YOUR OWN RESEARCH: >>> http://www.google.com/search?hl=en&q=intercage+malware >>> >>> You don't get called the ***American RBN*** for hosting a couple bad >>> machines. They >>> have and will continue to host much of the malware pumped out of America. >>> THEY >>> ARE NOT YOUR COMRADES.. >>> >>> These people represent the most HIGHLY ORGANZIED CRIME you will ever >>> come across. Most people were afraid to speak out against them until this >>> recent ground swell. >>> >>> This is the MALWARE CARTEL. GET THE PICTURE? >>> >>> Many links have been posted here that prove this already -- instead of >>> asking >>> what customers they cut off, let them show WHAT CUSTOMERS ARE LEGIT-- >>> because there are NONE. >>> >>> >>> >>> >>> >>>>>> I would suggest a different Step 1.? Instead of killing power, simply >>>>>> isolate the affected machine.? This might be as simple as putting up a >>>>>> firewall rule or two, if it is simply sending outgoing SMTP spam, or >>>>> it's probably easiest (depending on the network gear of course) to >>>>> just put the lan port into an isolated VLAN. It's not the 100% >>>>> solution (some badness rm's itself once it loses connectivity to the >>>>> internets) but it'd make things simpler for the client/LEA when they >>>>> need to figure out what happened. >>>>> >>>>> -chris >>>>> >>>>> >>>> >>>> >>> >>> >>> >>> >>> >> >> >> >> >> >> > > > > > > > From jgreco at ns.sol.net Wed Sep 24 06:40:30 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 24 Sep 2008 06:40:30 -0500 (CDT) Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <167064.96544.qm@web45006.mail.sp1.yahoo.com> from "Russell Mitchell" at Sep 23, 2008 10:29:08 PM Message-ID: <200809241140.m8OBeUkC079761@aurora.sol.net> > Hello Joe, > > If we can't power down the machine, due to evidence loss.?We > can't?nullroute the IP, as stated, some malware will delete > itself or alter itself when?Net Access is lost. > Now we can filter a single port, in the case of spam, phishing, etc? You can do whatever you need to, of course. The right thing to do is not always immediately apparent. Some time looking at the traffic on a mirror port (etc) can provide useful clues about how to proceed to an experienced professional. Unfortunately, my experience suggests that handling incidents on the "datacenter" side is a somewhat different skill set than handling the sorts of incidents that are commonly found on consumer Internet connections. The relative value of an infected machine approaches zero, while the value of a controlling system is fairly high, which implies that more effort may have been put into active defenses, which in turn implies other things. The "Geek Squad" or other "Nerds On Wheels" services are probably not going to be able to effectively clean off an impacted server, much less determine useful and clever ways to analyze what is going on, which is where it pays to have someone with contacts into the security community. Alas, I believe that all of this basic stuff should be immediately obvious and familiar to those in the hosting community, which leads me to other questions that are more along the lines of what others have been asking in this thread, and probably not relevant to NANOG. In the event that you are what you claim to be, rather than what many believe you to be based on past history and appearances, you would be well advised to make some contacts within the security community, and be prepared to acquire some expensive advice the next time you have an incident. You would need more help than you're going to be able to get on NANOG. And if you're what many people seem to think, well, tough. ... 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 jthomas at crucialservers.net Wed Sep 24 07:32:03 2008 From: jthomas at crucialservers.net (James Thomas) Date: Wed, 24 Sep 2008 08:32:03 -0400 Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer In-Reply-To: Message-ID: <20080924123538.8B9A061C20@crucialservers.net> Very well said. James -----Original Message----- From: michael.dillon at bt.com [mailto:michael.dillon at bt.com] Sent: Wednesday, September 24, 2008 5:23 AM To: nanog at nanog.org Subject: RE: YAY! Re: Atrivo/Intercage: NO Upstream depeer > It is clear to me -- at least -- that this entire criminal > operation is being operated out of Eastern Europe, and their > foothold in the U.S. is the major issue here. If you believe that this is a criminal operation then you should keep this discussion OFF THE LIST and discourage anyone from taking any action against the bad guys that might disrupt evidence gathering. If this is a criminal matter, then it is best to keep quiet, collect good evidence, and go to court. Better to get a court injunction ordering them to stop sending malware, and then collect evidence showing that they violated the injunction. To do this, they need to have functioning upstream connections to your network. NANOG is not the place to discuss these things. None of this is network operational. The whole discussion amounts to a shouting match between vigilantes and their victims. Some of those victims might also be bad guys, but a shouting match on NANOG does not prove this one way or the other. --Michael Dillon From rsk at gsp.org Wed Sep 24 07:50:58 2008 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 24 Sep 2008 08:50:58 -0400 Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <620fd17c0809240119o755a1717jb7492285e4763953@mail.gmail.com> References: <419009.17896.qm@web45010.mail.sp1.yahoo.com> <1bbf3c240809240114rdd80e46p90dbe4da1a34e3fd@mail.gmail.com> <620fd17c0809240119o755a1717jb7492285e4763953@mail.gmail.com> Message-ID: <20080924125058.GA12918@gsp.org> On Wed, Sep 24, 2008 at 04:19:16AM -0400, Paul Wall wrote: > Thanks to the efforts of the people on this list, you've known > Estdomains/Esthost was bad news for several weeks or more. > > Why are you only now shutting them down? "several weeks"? Try "several years". And do note the rationale (below) for the refusal to shut them down. > From Russ at Atrivo.com Sun Sep 4 13:58:23 EDT 2005 > Newsgroups: news.admin.net-abuse.blocklisting > From: Russ at Atrivo.com > Subject: Re: Atrivo/InterCage Abuse > Approved: NANAB Moderators > Injection-Info: f14g2000cwb.googlegroups.com; posting-host=69.107.73.156; > posting-account=2w8xwQ0AAADzda9cIvAir5JUpndTEjLg > Nntp-Posting-Date: Fri, 2 Sep 2005 17:48:03 +0000 (UTC) > Nntp-Posting-Host: 69.107.73.156 > X-Http-Useragent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322),gzip(gfe),gzip(gfe) > Organization: http://groups.google.com > Message-ID: <1125683278.320264.138150 at f14g2000cwb.googlegroups.com> > References: <1125616541.094735.138810 at z14g2000cwz.googlegroups.com> > <11hgs71j941hs0a at corp.supernews.com> > X-Trace: posting.google.com 1125683283 16154 127.0.0.1 (2 Sep 2005 17:48:03 GMT) > Date: Fri, 2 Sep 2005 19:51:13 GMT > X-Robomod: STUMP, ichudov at algebra.com (Igor Chudov), C++/Perl/Unix Consulting > > Hello fhh, > > There is no "network of esthost". The network in which Esthost resides > is our network. Esthost is one of our larger clients, They are very > successful in the industry of web hosting and domain registration. They > just recently became an ICANN Accredited Registrar. I won't comment on > "why" they're so successful... But for some, that may be obvious. > > I believe an investigation by law enforcement is a very corrective > step... That would definately clean Esthost up. > > I can honestly say, there are 2 of our major clients who are very > successful... and with both of those comes occasional abuse. On one, > it's the occasional spam via exploit. The other... Esthost... Well... A > lot worse abuse then just spam. > > One of the things I find quite rediculous is people have taken all of > our business emails from whois etc, and placed them in spam runs. How > stupid can you get?... Honestly! You have never received a spam email > that came from our business servers... Our clients (like EVERY other > companies clients) do get the abuse of spam from their servers. For all > of our clients (esthost aside)... This is not very often. We can't > please everyone. We try... But when you have to go through and work > with a client like esthost who doesn't quite take abuse too > seriously... and the only other thing you can do is null their client's > server.... it's hard to get a "correct" action taken. The correct > action on any intentional spammer is to be immediately removed. As well > as intentional virii distributors. This is seen with iframecash.biz... > We took reports from P Thompson and demanded their removal... That > appeared to be resolved... and then they pop up again. > > If I had the ability... I would cut Esthost as a client... But, in > doing so, it causes nearly a quarter if not half of the company's > monthly revenue to be cut. That is not too good of a move nor > reasonably possible ;) > > People consider Atrivo/InterCage to be some abuse supporting company... > If only any of you knew what the position would be in a company our > size. > > It's not as easy as you believe it to be ;) > > Thank you for your time. Have a great day. > > -- > Russell Mitchell - Russ[at]Atrivo.com > Atrivo Technologies > From trelane at trelane.net Wed Sep 24 08:40:35 2008 From: trelane at trelane.net (Andrew D Kirch) Date: Wed, 24 Sep 2008 09:40:35 -0400 Subject: Atrivo/Intercage In-Reply-To: <20080922203331.GA57011@web1.wotanworks.net> References: <20080922203331.GA57011@web1.wotanworks.net> Message-ID: <48DA4353.6000901@trelane.net> Tom Sparks (Applied Operations) wrote: > Basically is what it boils down to for me - its easy to blame > an NSP/ISP/Hoster for what their clients do, it takes real dedication to > find out whats *actually* going on. > We did, and now we're solving the problem. Andrew From surfer at mauigateway.com Wed Sep 24 09:06:41 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 24 Sep 2008 07:06:41 -0700 Subject: Atrivo/Intercage Message-ID: <20080924070641.8B7EEC6D@resin17.mta.everyone.net> --- trelane at trelane.net wrote: From: Andrew D Kirch > Basically is what it boils down to for me - its > easy to blame an NSP/ISP/Hoster for what their > clients do, it takes real dedication to find out > whats *actually* going on. : We did, and now we're solving the problem. ------------------------------------------ Apparently, this is what's going on. Making money at the expense of everyone else on the internet: --------------------------- > If I had the ability... I would cut Esthost as a > client... But, in doing so, it causes nearly a > quarter if not half of the company's monthly > revenue to be cut. That is not too good of a move > nor reasonably possible ;) > > People consider Atrivo/InterCage to be some abuse > supporting company... > > If only any of you knew what the position would be > in a company our size. > > It's not as easy as you believe it to be ;) > > Russell Mitchell - Russ[at]Atrivo.com > Atrivo Technologies ------------------------------ scott From hobbit at avian.org Wed Sep 24 08:37:43 2008 From: hobbit at avian.org (*Hobbit*) Date: Wed, 24 Sep 2008 13:37:43 +0000 (GMT) Subject: the Intercage mess Message-ID: <20080924133743.944847809@relayer.avian.org> While it's good to see some community effort going toward slapping a lid on misbehaving sources, how about a little consistency in the bigger picture? Consider this sort of scenario: An ISP allows its infrastructure to emit spam and host compromised machines to harbor malware and facilitate crime and botnets. Its abuse mailbox is a black hole that is provably ignored. All reasonable efforts to get the problem fixed fail. Network operators band together and deroute the ISP's blocks, forcing them to either clean up their act or find something else to do with their time. Internet death penalty, simple enough. If this happened to some of the other major sources of crap that I'm thinking of, it would make the freaking NATIONAL NEWS. Where's the BACKBONE to go after the real high-volume sources, rather than continuing to kick sand in the face of some podunk little guy who can no longer defend himself? _H* From trelane at trelane.net Wed Sep 24 09:33:38 2008 From: trelane at trelane.net (Andrew D Kirch) Date: Wed, 24 Sep 2008 10:33:38 -0400 Subject: the Intercage mess In-Reply-To: <20080924133743.944847809@relayer.avian.org> References: <20080924133743.944847809@relayer.avian.org> Message-ID: <48DA4FC2.6000505@trelane.net> *Hobbit* wrote: > Where's > the BACKBONE to go after the real high-volume sources, rather than > continuing to kick sand in the face of some podunk little guy who > can no longer defend himself? > > _H* > He never could defend himself, but he still hosts these companies (though months and years later he's finally terminated some of them). I have talked to over a dozen people who report abuse who are utterly perplexed at the tone taken by Intercage. I've SEEN archived abuse complaints from DronesBL, DOZENS of them. These reports aren't for compromised machines, they're for C&C's that host THOUSANDS of compromised machines each. When Gadi, when William Pitcock, when Spamhaus, when I, and DOZENS of others who watch these people say there's a problem, you'd best believe there's a problem. Andrew From ge at linuxbox.org Wed Sep 24 09:45:25 2008 From: ge at linuxbox.org (Gadi Evron) Date: Wed, 24 Sep 2008 09:45:25 -0500 (CDT) Subject: the Intercage mess In-Reply-To: <20080924133743.944847809@relayer.avian.org> References: <20080924133743.944847809@relayer.avian.org> Message-ID: On Wed, 24 Sep 2008, *Hobbit* wrote: > While it's good to see some community effort going toward slapping > a lid on misbehaving sources, how about a little consistency in > the bigger picture? > > Consider this sort of scenario: An ISP allows its infrastructure > to emit spam and host compromised machines to harbor malware and > facilitate crime and botnets. Its abuse mailbox is a black hole > that is provably ignored. All reasonable efforts to get the problem > fixed fail. Network operators band together and deroute the ISP's > blocks, forcing them to either clean up their act or find something > else to do with their time. Internet death penalty, simple enough. > > If this happened to some of the other major sources of crap that > I'm thinking of, it would make the freaking NATIONAL NEWS. Where's > the BACKBONE to go after the real high-volume sources, rather than > continuing to kick sand in the face of some podunk little guy who > can no longer defend himself? This was one of the big guys, it's not their fault they did all that mess from less IP space. It's like folks who say .biz, .info or .name are worse than .com. Obviously .com has more abuse but it is lost in the noise of the regular hugeness of its traffic. > _H* > From taylor at dec0de.org Wed Sep 24 10:05:11 2008 From: taylor at dec0de.org (Taylor Neill) Date: Wed, 24 Sep 2008 11:05:11 -0400 Subject: seeking AOL postmaster with clue... (sorry) Message-ID: I'm pretty much ready to take my life over having to deal with AOL's Postmaster. If anyone has a contact or lead at AOL with a clue, could you please respond off-list? I am at wits end. A thousand apologies for the noise, Taylor Neill From psirt at cisco.com Wed Sep 24 10:50:00 2008 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 24 Sep 2008 17:50:00 +0200 Subject: Cisco Security Advisory: Cisco IOS IPS Denial of Service Vulnerability Message-ID: <200809241750.iosips@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco IOS IPS Denial of Service Vulnerability Advisory ID: cisco-sa-20080924-iosips http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosips.shtml Revision 1.0 For Public Release 2008 September 24 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= The Cisco IOS Intrusion Prevention System (IPS) feature contains a vulnerability in the processing of certain IPS signatures that use the SERVICE.DNS engine. This vulnerability may cause a router to crash or hang, resulting in a denial of service condition. Cisco has released free software updates that address this vulnerability. There is a workaround for this vulnerability. Note: This vulnerability is not related in any way to CVE-2008-1447 - Cache poisoning attacks. Cisco Systems has published a Cisco Security Advisory for that vulnerability, which can be found at http://www.cisco.com/en/US/products/products_security_advisory09186a00809c2168.shtml This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosips.shtml Note: The September 24, 2008 IOS Advisory bundled publication includes twelve Security Advisories. Eleven of the advisories address vulnerabilities in Cisco's IOS software, and one advisory addresses vulnerabilities in Cisco Unified Communications Manager. Each Advisory lists the releases that correct the vulnerability described in the Advisory. Please reference the following software table to find a release that fixes all published IOS software Advisories as of September 24th, 2008: http://www.cisco.com/warp/public/707/cisco-sa-20080924-bundle.shtml Individual publication links are listed below: * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ssl.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sip.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-cucm.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-vpn.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-mfi.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ipc.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ubr.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-multicast.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sccp.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosfw.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-l2tp.shtml Affected Products ================= Vulnerable Products +------------------ Any Cisco IOS device configured with the Cisco IOS IPS feature is vulnerable, regardless if it is configured to use the built-in signatures or an external signature file. Devices using either version 4 or version 5 signatures are affected by this vulnerability. The Cisco IOS IPS feature is not enabled by default. The command show ip ips interfaces can be used to determine if the Cisco IOS IPS feature has been configured and applied to any interface on the device, as in the following example: Router#show ip ips interfaces Interface Configuration Interface FastEthernet0/0 Inbound IPS rule is ios-ips-incoming Outgoing IPS rule is not set Interface FastEthernet0/1 Inbound IPS rule is not set Outgoing IPS rule is ios-ips-outgoing Router# The output of the show ip ips interfaces command when the Cisco IOS IPS feature has not been configured is dependent on which Cisco IOS release is installed and running on the device. It may be similar to the following example: Router#show ip ips interfaces Router# or it may be similar to the following: Router#show ip ips interfaces Interface Configuration IPS is not configured on any interface Router# Any version of Cisco IOS prior to the versions which are listed in the Software Versions and Fixes section below is vulnerable. To determine the version of the Cisco IOS software running on a Cisco product, log in to the device and issue the show version command to display the system banner. Cisco IOS software will identify itself as "Internetwork Operating System Software" or simply "IOS". On the next line of output, the image name will be displayed between parentheses, followed by "Version" and the IOS release name. Other Cisco devices will not have the show version command or will give different output. The following example identifies a Cisco product running Cisco IOS Software release 12.3(26) with an installed image name of C2500-IS-L: Router#show version Cisco Internetwork Operating System Software IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by cisco Systems, Inc. Compiled Mon 17-Mar-08 14:39 by dchih Router# The next example shows a product running Cisco IOS Software release 12.4(20)T with an image name of C1841-ADVENTERPRISEK9-M: Router#show version Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by Cisco Systems, Inc. Compiled Thu 10-Jul-08 20:25 by prod_rel_team Router# Additional information on the Cisco IOS release naming conventions can be found on the document entitled "White Paper: Cisco IOS Reference Guide", which is available at http://www.cisco.com/warp/public/620/1.html Products Confirmed Not Vulnerable +-------------------------------- The following Cisco products are confirmed not vulnerable: * Cisco IOS devices running the Intrusion Detection System feature * Cisco ASA Security Appliances running the Intrusion Detection System feature * Cisco PIX 500 Series Security Appliances running the Intrusion Detection System feature * Cisco IPS 4200 Sensors * Cisco AIP-SSM for ASA 5500 Series Adaptive Security Appliances * Cisco Catalyst 6500 Series Intrusion detection System (IDSM-2) Services Module * Cisco IPS Advanced Integration Module for Integrated Services Routers No other Cisco products are currently known to be affected by this vulnerability. Details ======= Cisco IOS Intrusion Prevention System (IPS) is an inline, deep-packet inspection feature that effectively mitigates a wide range of network attacks. A component of the Cisco IOS Integrated Threat Control framework and complemented by Cisco IOS Flexible Packet Matching feature, Cisco IOS IPS provides your network with the intelligence to accurately identify, classify, and stop or block malicious traffic in real time. Additional information on the Cisco IOS IPS feature can be found at http://www.cisco.com/en/US/docs/ios/12_3t/12_3t8/feature/guide/gt_fwids.html Previous to the introduction of the Cisco IOS IPS feature, Cisco IOS provided a similar feature, the Cisco IOS Intrusion Detection System (IDS). The Cisco IOS IDS feature is not affected by this vulnerability. Additional information on the Cisco IOS IDS feature can be found at http://www.cisco.com/en/US/docs/ios/12_0t/12_0t5/feature/guide/ios_ids.html Certain network traffic can trigger IPS signatures on the SERVICE.DNS signature engine which may cause the Cisco IOS device to crash or hang. This may cause a denial of service that results in disruption of network traffic. This vulnerability is documented in Cisco Bug ID CSCsq13348. This vulnerability has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2008-2739. 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 CSCsq13348 - Watchdog timeout with IPS configured CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of this vulnerability may cause a Cisco IOS device configured with the Cisco IOS IPS feature to crash or hang, resulting in a denial of service condition. 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. Each row of the Cisco IOS software table (below) names a Cisco IOS 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 Repaired Releases | | Release | | |------------+------------------------------------------------------| | Affected | | Recommended | | 12.0-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.0 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.1-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.1 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.2-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.2 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.3-Based | First Fixed Release | Release | | Releases | | | |------------+--------------------------------------+---------------| | 12.3 | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3B | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3BC | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3BW | Not Vulnerable | | |------------+--------------------------------------+---------------| | 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 | | |------------+--------------------------------------+---------------| | | | 12.4(15)T7 | | 12.3T | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+--------------------------------------+---------------| | 12.3TPC | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3VA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XB | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XC | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XD | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XE | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XF | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XG | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XI | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XJ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XK | Not Vulnerable | | |------------+--------------------------------------+---------------| | | | 12.4(15)T7 | | 12.3XL | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+--------------------------------------+---------------| | | | 12.4(15)T7 | | 12.3XQ | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+--------------------------------------+---------------| | | | 12.4(15)T7 | | 12.3XR | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+--------------------------------------+---------------| | | | 12.4(15)T7 | | 12.3XS | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+--------------------------------------+---------------| | 12.3XU | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XW | Not Vulnerable | | |------------+--------------------------------------+---------------| | | | 12.4(15)T7 | | 12.3XX | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+--------------------------------------+---------------| | 12.3XY | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3XZ | Not Vulnerable | | |------------+--------------------------------------+---------------| | | | 12.4(15)T7 | | 12.3YA | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+--------------------------------------+---------------| | 12.3YD | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+--------------------------------------+---------------| | 12.3YF | Not Vulnerable | | |------------+--------------------------------------+---------------| | | Releases prior to 12.3(8)YG7 are | | | 12.3YG | vulnerable, release 12.3(8)YG7 and | 12.4(15)T7 | | | later are not vulnerable; first | | | | fixed in 12.4T | | |------------+--------------------------------------+---------------| | 12.3YH | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+--------------------------------------+---------------| | 12.3YI | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+--------------------------------------+---------------| | 12.3YJ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3YK | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+--------------------------------------+---------------| | | | 12.3(14)YM13; | | 12.3YM | 12.3(14)YM13; Available on 30-SEP-08 | Available on | | | | 30-SEP-08 | |------------+--------------------------------------+---------------| | 12.3YQ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3YS | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+--------------------------------------+---------------| | 12.3YT | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+--------------------------------------+---------------| | 12.3YU | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3YX | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.3YZ | Vulnerable; contact TAC | | |------------+--------------------------------------+---------------| | 12.3ZA | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+--------------------------------------+---------------| | Affected | | Recommended | | 12.4-Based | First Fixed Release | Release | | Releases | | | |------------+--------------------------------------+---------------| | | 12.4(18b) | | | | | | | 12.4 | 12.4(19a) | 12.4(18c) | | | | | | | 12.4(21) | | |------------+--------------------------------------+---------------| | 12.4JA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JK | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JL | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JMA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JMB | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JMC | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JX | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4MD | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4MR | 12.4(19)MR | 12.4(19)MR | |------------+--------------------------------------+---------------| | 12.4SW | Not Vulnerable | | |------------+--------------------------------------+---------------| | | 12.4(15)T6 | | | 12.4T | | 12.4(15)T7 | | | 12.4(20)T | | |------------+--------------------------------------+---------------| | 12.4XA | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+--------------------------------------+---------------| | 12.4XB | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XC | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+--------------------------------------+---------------| | | | 12.4(4)XD11; | | 12.4XD | 12.4(4)XD11; Available on 26-SEP-08 | Available on | | | | 26-SEP-08 | |------------+--------------------------------------+---------------| | 12.4XE | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+--------------------------------------+---------------| | 12.4XF | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+--------------------------------------+---------------| | 12.4XG | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XJ | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+--------------------------------------+---------------| | 12.4XK | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+--------------------------------------+---------------| | 12.4XL | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XM | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XN | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XP | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XQ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XT | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+--------------------------------------+---------------| | 12.4XV | Vulnerable; contact TAC | | |------------+--------------------------------------+---------------| | 12.4XW | 12.4(11)XW9 | 12.4(11)XW9 | |------------+--------------------------------------+---------------| | 12.4XY | 12.4(15)XY4 | 12.4(15)XY4 | |------------+--------------------------------------+---------------| | 12.4XZ | 12.4(15)XZ2 | 12.4(15)XZ2 | |------------+--------------------------------------+---------------| | 12.4YA | 12.4(20)YA1 | 12.4(20)YA1 | +-------------------------------------------------------------------+ Workarounds =========== The workaround consists of adding an Access Control List (ACL) to every Cisco IOS IPS policy configured on the device so that traffic destined to ports 53/udp or 53/tcp is not inspected by the Cisco IOS IPS feature. The following ACL would need to be added to the device configuration: ! deny inspection of traffic with a destination port of 53/udp access-list 177 deny udp any any eq 53 ! deny inspection of traffic with a destination port of 53/tcp access-list 177 deny tcp any any eq 53 ! allow all other traffic to be inspected access-list 177 permit ip any any Every instance of a Cisco IOS IPS policy on the device would then need to be modified in order to reference the previous ACL. In order to determine which Cisco IOS IPS policies are configured on the device, execute the command show running-config | include ip ips name as in the following example: Router#show running-config | include ip ips name ip ips name ios-ips-incoming ip ips name ios-ips-outgoing Router# In the previous example, two Cisco IOS IPS policies are configured on the device. The following example shows the addition of an ACL to each one of the Cisco IOS IPS policies previously identified: Router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)#ip ips name ios-ips-incoming list 177 Router(config)#ip ips name ios-ips-outgoing list 177 Router(config)#end Router# As a verification step, the command show ip ips interfaces can be executed again to verify the ACL has been properly attached to each one of the Cisco IOS IPS policies: Router#show ip ips interfaces Interface Configuration Interface FastEthernet0/0 Inbound IPS rule is ios-ips-incoming acl list 177 Outgoing IPS rule is not set Interface FastEthernet0/1 Inbound IPS rule is not set Outgoing IPS rule is ios-ips-outgoing acl list 177 Router# Note: Disabling or deleting individual or all signatures using the SERVICE.DNS engine of the Cisco IOS IPS feature is not a recommended workaround. The previous workaround is the only Cisco-recommended workaround for this vulnerability. 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. This vulnerability was reported to Cisco by a customer. 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-20080924-iosips.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-bulletins at lists.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 | | Initial | | 1.0 | 2008-September-24 | 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjaLb4ACgkQ86n/Gc8U/uCOcQCfVtBrGIC3MJQr9jaPkMlt3ikc XrEAn1XOyW6nTAO/lsY5edWYzRoTuLDe =HgRp -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 24 10:50:00 2008 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 24 Sep 2008 17:50:00 +0200 Subject: Cisco Security Advisory: Cisco IOS Software Firewall Application Inspection Control Vulnerability Message-ID: <200809241750.iosfw@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco IOS Software Firewall Application Inspection Control Vulnerability Advisory ID: cisco-sa-20080924-iosfw http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosfw.shtml Revision 1.0 For Public Release 2008 September 24 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= Cisco IOS software configured for IOS firewall Application Inspection Control (AIC) with a HTTP configured application-specific policy are vulnerable to a Denial of Service when processing a specific malformed HTTP transit packet. Successful exploitation of the vulnerability may result in a reload of the affected device. Cisco has released free software updates that address this vulnerability. A mitigation for this vulnerability is available. See the "Workarounds" section for details. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosfw.shtml Note: The September 24, 2008 IOS Advisory bundled publication includes twelve Security Advisories. Eleven of the advisories address vulnerabilities in Cisco's IOS software, and one advisory addresses vulnerabilities in Cisco Unified Communications Manager. Each Advisory lists the releases that correct the vulnerability described in the Advisory. Please reference the following software table to find a release that fixes all published IOS software Advisories as of September 24th, 2008: http://www.cisco.com/warp/public/707/cisco-sa-20080924-bundle.shtml Individual publication links are listed below: * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosips.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ssl.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sip.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-cucm.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-vpn.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-mfi.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ipc.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ubr.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-multicast.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sccp.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-l2tp.shtml Affected Products ================= The HTTP AIC feature was introduced in Cisco IOS Software Release 12.4(9)T. The software table in this advisory identifies the affected releases. Vulnerable Products +------------------ Devices that are running a vulnerable version of Cisco IOS software and configured for Cisco IOS firewall AIC for HTTP are affected. To determine the software running on a Cisco IOS product, log in to the device and issue the show version command-line interface (CLI) command to display the system banner. Cisco IOS software will identify itself as "Internetwork Operating System Software" or simply "IOS." On the next line of output, the image name will be displayed between parentheses, followed by "Version" and the Cisco IOS release name. Other Cisco devices will not have the show version command, or will give different output. The following example shows output from a device running Cisco IOS image 12.4(15)T2: router#show version Cisco IOS Software, 1841 Software (C1841-ADVSECURITYK9-M), Version 12.4(15)T2, RELEASE SOFTWARE (fc7) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by Cisco Systems, Inc. Compiled Thu 17-Jan-08 23:12 by prod_rel_team !--- Output truncated. Additional information on the Cisco IOS release naming conventions can be found on the document entitled "White Paper: Cisco IOS Reference Guide", which is available at http://www.cisco.com/warp/public/620/1.html The device is vulnerable if the configuration has a Layer 7 class map and Layer 7 policy map for HTTP deep packet inspection (DPI), and these policies are applied to any firewall zone. To determine whether the device is running a vulnerable configuration of Cisco IOS firewall AIC for HTTP, log in to the device and issue the CLI command show policy-map type inspect zone-pair | section packet inspection. If the output contains Policy: http layer7-policymap name , the device is vulnerable. The following example shows the response from a vulnerable device: Router#show policy-map type inspect zone-pair | section packet inspection Deep packet inspection Policy: http layer7-policymap 1 packets, 28 bytes Router# Products Confirmed Not Vulnerable +-------------------------------- No other Cisco products are currently known to be affected by this vulnerability. IOS releases before 12.4(9)T are not affected by this issue. Products confirmed not vulnerable include: * Cisco PIX * Cisco ASA * Cisco Firewall Services Module (FWSM) * The Virtual Firewall (VFW) application on the multiservice blade (MSB) on the Cisco XR 12000 Series Router Details ======= Firewalls are networking devices that control access to an organization's network assets. Firewalls are often positioned at the entrance points into networks. Cisco IOS software provides a set of security features that enable you to configure a simple or elaborate firewall policy, according to your particular requirements. HTTP uses port 80 by default to transport Internet web services, which are commonly used on the network and rarely challenged with regard to their legitimacy and conformance to standards. Because port 80 traffic is typically allowed through the network without being challenged, many application developers are leveraging HTTP traffic as an alternative transport protocol that will allow their application's traffic to travel through or even bypass the firewall. When the Cisco IOS Firewall is configured with HTTP AIC, it performs packet inspection to detect HTTP connections that are not authorized in the scope of the security policy configuration. It also detects users who are tunneling applications through port 80. If the packet is not in compliance with the HTTP protocol, it will be dropped, the connection will be reset, and a syslog message will be generated, as appropriate. Cisco IOS Software that is configured for IOS firewall AIC with an HTTP application-specific policy is vulnerable to a denial of service condition when it processes a specific malformed HTTP transit packet. Successful exploitation of the vulnerability may result in a reload of the affected device. HTTP runs over TCP. For this vulnerability to be exploited, a full three-way handshake between client and server is required before any malicious traffic would be processed to result in a device reload. Additional information regarding Cisco IOS Firewall AIC with HTTP application-specific policy maps is available at http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124newft/124t/124t6/htzonebp.htm#wp1407906 This vulnerability is documented in Cisco bug ID CSCsh12480 and Common Vulnerabilities and Exposures (CVE) identifier CVE-2008-3812 has been assigned to this vulnerability. Vulnerability Scoring Details ============================= Cisco has provided scores for the vulnerability 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 CSCsh12480 - IOSFW with HTTP AIC may reload on processing crafted HTTP packet CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of the vulnerability may result in a reload of the affected device. Repeated exploitation attempts may result in a sustained denial of service attack. 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. Each row of the Cisco IOS software table (below) names a Cisco IOS 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 Release | Availability of Repaired Releases | |-----------------+-------------------------------------------------| | Affected | | Recommended | | 12.0-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.0 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.1-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.1 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.2-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.2 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.3-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.3 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.4-Based | First Fixed Release | Release | | Releases | | | |-----------------+-----------------------------------+-------------| | 12.4 | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4JA | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4JK | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4JL | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4JMA | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4JMB | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4JMC | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4JX | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4MD | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4MR | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4SW | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | | Releases prior to 12.4(9)T are | | | | not vulnerable. First fixed in: | | | | | | | 12.4T | 12.4(9)T7 | 12.4(15)T7 | | | | | | | 12.4(11)T4 | | | | | | | | 12.4(15)T | | |-----------------+-----------------------------------+-------------| | 12.4XA | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4XB | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4XC | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4XD | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4XE | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |-----------------+-----------------------------------+-------------| | 12.4XF | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4XG | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4XJ | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |-----------------+-----------------------------------+-------------| | 12.4XK | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |-----------------+-----------------------------------+-------------| | 12.4XL | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4XM | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4XN | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4XP | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4XQ | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4XT | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4XV | Vulnerable; contact TAC | | |-----------------+-----------------------------------+-------------| | 12.4XW | 12.4(11)XW1 | 12.4(11)XW9 | |-----------------+-----------------------------------+-------------| | 12.4XY | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4XZ | Not Vulnerable | | |-----------------+-----------------------------------+-------------| | 12.4YA | Not Vulnerable | | +-------------------------------------------------------------------+ Workarounds =========== There are no known workarounds for this vulnerability. The only known action to help counter this vulnerability is to disable AIC HTTP deep packet inspection in the affected device's configuration. Disabling deep packet HTTP inspection will allow the rest of the firewall features to continue to function until a software upgrade can be implemented. All other firewall features will continue to perform normally. Disabling AIC HTTP Deep Packet Inspection +---------------------------------------- To disable AIC HTTP Deep Packet Inspection, remove the linkage between policy-map type inspect layer4-policymap and policy-map type inspect http layer7-policymap. This example shows an existing configuration, followed by how to remove AIC HTTP Deep Packet Inspection: !--- Existing Configuration ! parameter-map type inspect global ! class-map type inspect http match-any layer7-classmap class-map type inspect match-any layer4-classmap match protocol http ! policy-map type inspect http layer7-policymap class type inspect http layer7-classmap allow class class-default policy-map type inspect layer4-policymap class type inspect layer4-classmap inspect global service-policy http layer7-policymap class class-default ! zone security inside description ** Inside Network ** zone security outside description ** Outside Network ** zone-pair security in2out source inside destination outside description ** Zone Pair - inside to outside ** service-policy type inspect layer4-policymap Remove the service-policy from the zone-pair in question: Router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)#zone-pair security in2out source inside destination outside Router(config-sec-zone-pair)#no service-policy type inspect layer4-policymap Router(config-sec-zone-pair)#exit Remove the linkage between policy-map type inspect layer4-policymap and policy-map type inspect http layer7-policymap: Router(config)#policy-map type inspect layer4-policymap Router(config-pmap)#class type inspect layer4-classmap Router(config-pmap-c)#no service-policy http layer7-policymap Router(config-pmap-c)#exit Router(config-pmap)#exit Reapply the service-policy to the zone-pair in question: Router(config)#zone-pair security in2out source inside destination outside Router(config-sec-zone-pair)#service-policy type inspect layer4-policymap Router(config-sec-zone-pair)#exit Although not required, for completeness of the configuration the policy-map type inspect http layer7-policymap and class-map type inspect http match-any layer7-classmap are recommended to be removed. Router(config)#no policy-map type inspect http layer7-policymap Router(config)#no class-map type inspect http match-any layer7-classmap Router(config)#exit Router# Obtaining Fixed Software ======================== Cisco has released free software updates that address this vulnerability. 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. This vulnerability was found by Cisco internal testing. 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-20080924-iosfw.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-bulletins at lists.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 | | Initial | | 1.0 | 2008-September-24 | 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjaLbkACgkQ86n/Gc8U/uBSqwCgi7dmsFhp1u9fxWgLqVpMPtV+ fuIAn3f11gNGT/LITk11YI6fjv7W1Q20 =0tmt -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 24 10:50:00 2008 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 24 Sep 2008 17:50:00 +0200 Subject: Cisco Security Advisory: Cisco 10000, uBR10012, uBR7200 Series Devices IPC Vulnerability Message-ID: <200809241750.ipc@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco 10000, uBR10012, uBR7200 Series Devices IPC Vulnerability Advisory ID: cisco-sa-20080924-ipc http://www.cisco.com/warp/public/707/cisco-sa-20080924-ipc.shtml Revision 1.0 For Public Release 2008 September 24 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= Cisco 10000, uBR10012 and uBR7200 series devices use a User Datagram Protocol (UDP) based Inter-Process Communication (IPC) channel that is externally reachable. An attacker could exploit this vulnerability to cause a denial of service (DoS) condition on affected devices. No other platforms are affected. Cisco has released free software updates that address this vulnerability. Workarounds that mitigate this vulnerability are available. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20080924-ipc.shtml Note: The September 24, 2008 IOS Advisory bundled publication includes twelve Security Advisories. Eleven of the advisories address vulnerabilities in Cisco's IOS^ software, and one advisory addresses vulnerabilities in Cisco Unified Communications Manager. Each Advisory lists the releases that correct the vulnerability described in the Advisory. Please reference the following software table to find a release that fixes all published IOS software Advisories as of September 24th, 2008: http://www.cisco.com/warp/public/707/cisco-sa-20080924-bundle.shtml Individual publication links are listed below: * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosips.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ssl.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sip.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-cucm.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-vpn.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-mfi.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ubr.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-multicast.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sccp.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosfw.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-l2tp.shtml Affected Products ================= Cisco 10000, uBR10012 and uBR7200 series devices that are running an affected version of Cisco IOS are affected. Vulnerable Products +------------------ Devices that are running Cisco IOS can be identified by using the show version command. The following example shows an output taken from a Cisco 10000 series device running Cisco IOS software release 12.2(31)SB10e: c10k#show version | include IOS Cisco IOS Software, 10000 Software (C10K3-P11-M), Version 12.2(31)SB10e, RELEASE SOFTWARE (fc1) c10k# The following example shows an output taken from a Cisco uBR10012 series device running Cisco IOS software release 12.3(17b)BC7: ubr10k#show version | include IOS IOS (tm) 10000 Software (UBR10K-K8P6U2-M), Version 12.3(17b)BC7, RELEASE SOFTWARE (fc1) ubr10k# The following example shows an output taken from a Cisco uBR7200 series device running Cisco IOS software release 12.3(21a)BC2: ubr7200#show version | include IOS IOS (tm) 7200 Software (UBR7200-IK9SU2-M), Version 12.3(21a)BC2, RELEASE SOFTWARE (fc1) ubr7200# Please refer to the document entitled "White Paper: Cisco IOS Reference Guide" for additional information on the Cisco IOS release naming conventions. This document is available at the following link: http://www.cisco.com/warp/public/620/1.html Any version of Cisco IOS prior to the fixed versions listed in the Software Versions and Fixes section below is vulnerable. Products Confirmed Not Vulnerable +-------------------------------- Cisco uBR7100 series devices are not affected. No other Cisco products are currently known to be affected by this vulnerability. Details ======= Cisco 10000, uBR10012 and uBR7200 series devices use a UDP-based IPC channel. This channel uses addresses from the 127.0.0.0/8 range and UDP port 1975. Cisco 10000, uBR10012 and uBR7200 series devices that are running an affected version of Cisco IOS will process IPC messages that are sent to UDP port 1975 from outside of the device. This behavior may be exploited by an attacker to cause a reload of the device, linecards, or both, resulting in a DoS condition. Filtering unauthorized traffic destined to 127.0.0.0/8 or UDP port 1975 will mitigate this vulnerability. This vulnerability is documented in the Cisco Bug IDs CSCsg15342 and CSCsh29217 and has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2008-3805. 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 CSCsg15342 - IPC processing needs to be more robust CVSS Base Score - 8.5 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - Partial Availability Impact - Complete CVSS Temporal Score - 7 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed CSCsh29217 - IPC processing needs to be more robust CVSS Base Score - 8.5 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - Partial Availability Impact - Complete CVSS Temporal Score - 7 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of the vulnerability may result in a reload of the device, linecards, or both, resulting in a DoS condition. 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. Each row of the Cisco IOS software table (below) names a Cisco IOS 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 Repaired Releases | | Release | | |-------------+-----------------------------------------------------| | Affected | | Recommended | | 12.0-Based | First Fixed Release | Release | | Releases | | | |-------------+-------------------------------------+---------------| | 12.0 | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0DA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0DB | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0DC | Not Vulnerable | | |-------------+-------------------------------------+---------------| | | Releases prior to 12.0(32)S are | 12.0(32)S11 | | 12.0S | vulnerable, release 12.0(32)S and | | | | later are not vulnerable; | 12.0(33)S1 | |-------------+-------------------------------------+---------------| | 12.0SC | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0SL | Vulnerable, migrate to 12.0S, 12.1 | | |-------------+-------------------------------------+---------------| | 12.0SP | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0ST | Vulnerable, migrate to 12.0S, 12.1 | | |-------------+-------------------------------------+---------------| | 12.0SX | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0SY | Not Vulnerable | | |-------------+-------------------------------------+---------------| | | | 12.0(32)S11 | | 12.0SZ | 12.0(30)SZ4 | | | | | 12.0(33)S1 | |-------------+-------------------------------------+---------------| | 12.0T | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0W | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0WC | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0WT | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XB | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XC | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XD | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XE | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XF | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XG | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XH | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XI | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XJ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XK | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XL | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XM | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XN | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XQ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XR | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XS | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XT | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.0XV | Not Vulnerable | | |-------------+-------------------------------------+---------------| | Affected | | Recommended | | 12.1-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.1 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.2-Based | First Fixed Release | Release | | Releases | | | |-------------+-------------------------------------+---------------| | 12.2 | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2B | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2BC | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2BW | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2BX | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2BY | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2BZ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2CX | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2CY | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2CZ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2DA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2DD | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2DX | 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.2IRB | 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.2IXG | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2JA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2JK | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2MB | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2MC | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2S | Not Vulnerable | | |-------------+-------------------------------------+---------------| | | 12.2(31)SB13 | 12.2(33)SB2; | | 12.2SB | | Available on | | | 12.2(33)SB1 | 26-SEP-08 | |-------------+-------------------------------------+---------------| | 12.2SBC | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2SCA | 12.2(33)SCA1 | 12.2(33)SCA1 | |-------------+-------------------------------------+---------------| | 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 | 12.2(33)SRC2 | 12.2(33)SRC2 | |-------------+-------------------------------------+---------------| | 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.2SY | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2SZ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2T | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2TPC | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XB | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XC | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XD | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XE | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XF | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XG | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XH | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XI | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XJ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XK | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XL | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XM | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XN | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XNA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XNB | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XO | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XQ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XR | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XS | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XT | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2XU | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 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 | | |-------------+-------------------------------------+---------------| | 12.2YJ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YK | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YL | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YM | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YN | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YO | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YP | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YQ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YR | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YS | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YT | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YU | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YV | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YW | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YX | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YY | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2YZ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2ZA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2ZB | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2ZC | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2ZD | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2ZE | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2ZF | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2ZG | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2ZH | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2ZJ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2ZL | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2ZP | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2ZU | Not Vulnerable | | |-------------+-------------------------------------+---------------| | | | 12.2(33)SB2; | | 12.2ZX | Vulnerable; first fixed in 12.2SB | Available on | | | | 26-SEP-08 | |-------------+-------------------------------------+---------------| | 12.2ZY | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.2ZYA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | Affected | | Recommended | | 12.3-Based | First Fixed Release | Release | | Releases | | | |-------------+-------------------------------------+---------------| | 12.3 | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3B | Not Vulnerable | | |-------------+-------------------------------------+---------------| | | 12.3(17b)BC6 | | | | | | | 12.3BC | 12.3(21a)BC1 | 12.3(23)BC4 | | | | | | | 12.3(23)BC | | |-------------+-------------------------------------+---------------| | 12.3BW | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 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 | | |-------------+-------------------------------------+---------------| | | Note: Releases prior to 12.3(14)T3 | 12.4(15)T7 | | 12.3T | are vulnerable, release 12.3(14)T3 | | | | and later are not vulnerable; | 12.4(18c) | |-------------+-------------------------------------+---------------| | 12.3TPC | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3VA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3XA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3XB | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3XC | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3XD | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3XE | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3XF | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3XG | Not Vulnerable | | |-------------+-------------------------------------+---------------| | | | 12.2(33)SB2; | | 12.3XI | 12.3(7)XI10a | Available on | | | | 26-SEP-08 | |-------------+-------------------------------------+---------------| | 12.3XJ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3XK | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3XL | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3XQ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3XR | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3XS | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3XU | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3XW | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3XX | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3XY | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3XZ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3YA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3YD | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3YF | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3YG | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3YH | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3YI | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3YJ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3YK | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3YM | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3YQ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3YS | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3YT | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3YU | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3YX | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3YZ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.3ZA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | Affected | | Recommended | | 12.4-Based | First Fixed Release | Release | | Releases | | | |-------------+-------------------------------------+---------------| | | Note: Releases prior to 12.4(3) are | | | 12.4 | vulnerable, release 12.4(3) and | 12.4(18c) | | | later are not vulnerable; | | |-------------+-------------------------------------+---------------| | 12.4JA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4JK | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4JL | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4JMA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4JMB | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4JMC | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4JX | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4MD | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4MR | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4SW | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4T | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XA | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XB | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XC | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XD | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XE | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XF | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XG | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XJ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XK | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XL | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XM | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XN | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XP | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XQ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XR | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XT | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XV | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XW | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XY | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4XZ | Not Vulnerable | | |-------------+-------------------------------------+---------------| | 12.4YA | Not Vulnerable | | +-------------------------------------------------------------------+ Workarounds =========== Workarounds consist of filtering packets that are sent to 127.0.0.0/8 range and UDP packets that are sent to port 1975. Using Interface Access Control Lists +----------------------------------- Access lists that filter UDP packets destined to port 1975 can be used to mitigate this vulnerability. UDP port 1975 is a registered port number that can be used by certain applications. However, filtering all packets that are destined to UDP port 1975 may cause some applications to malfunction. Therefore, access lists need to explicitly deny UDP 1975 packets that are sent to any router interface IP addresses and permit transit traffic. Such access lists need to be applied on all interfaces to be effective. Since the IPC channel uses addresses from the 127.0.0.0/8 range, it is also necessary to filter packets that are sourced from or destined to this range. An example is given below: access-list 100 deny udp any host eq 1975 access-list 100 deny udp any host eq 1975 access-list 100 deny udp any host eq 1975 access-list 100 deny ip 127.0.0.0 0.255.255.255 any access-list 100 deny ip any 127.0.0.0 0.255.255.255 access-list 100 permit ip any any interface Serial 0/0 ip access-group 100 in Using Control Plane Policing +--------------------------- Control Plane Policing (CoPP) can be used to block untrusted UDP port 1975 access to the affected device. Cisco IOS software releases 12.2BC and 12.2SCA support the CoPP feature. CoPP may be configured on a device to protect the management and control planes to minimize the risk and effectiveness of direct infrastructure attacks by explicitly permitting only authorized traffic sent to infrastructure devices in accordance with existing security policies and configurations. The following example can be adapted to your network. Note: CoPP is not supported on uBR10012 series devices. !-- Permit all UDP/1975 traffic so that it !-- will be policed and dropped by the CoPP feature ! access-list 111 permit udp any any eq 1975 access-list 111 permit ip any 127.0.0.0 0.255.255.255 access-list 111 permit ip 127.0.0.0 0.255.255.255 any ! !-- Permit (Police or Drop)/Deny (Allow) all other Layer 3 and !-- Layer 4 traffic in accordance with existing security policies !-- and configurations for traffic that is authorized to be sent !-- to infrastructure devices ! !-- Create a Class-Map for traffic to be policed by the CoPP !-- feature ! class-map match-all drop-IPC-class match access-group 111 ! !-- Create a Policy-Map that will be applied to the Control-Plane !-- of the device ! policy-map drop-IPC-traffic class drop-IPC-class drop ! !-- Apply the Policy-Map to the Control-Plane of the device ! control-plane service-policy input drop-IPC-traffic ! In the above CoPP example, the access control list entries (ACEs) which match the potential exploit packets with the "permit" action result in these packets being discarded by the policy-map "drop" function, while packets that match the "deny" action (not shown) are not affected by the policy-map drop function. Please note that in the Cisco IOS 12.2S and 12.0S trains the policy-map syntax is different: ! policy-map drop-IPC-traffic class drop-IPC-class police 32000 1500 1500 conform-action drop exceed-action drop ! Additional information on the configuration and use of the CoPP feature can be found at http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html, http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6642/prod_white_paper0900aecd804fa16a.html and http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtrtlimt.html Using Infrastructure ACLs at Network Boundary +-------------------------------------------- Although it is often difficult to block traffic transiting your network, it is possible to identify traffic which should never be allowed to target your infrastructure devices and block that traffic at the border of your network. iACLs are a network security best practice and should be considered as a long-term addition to good network security as well as a workaround for this specific vulnerability. The iACL example shown below should be included as part of the deployed infrastructure access-list which will protect all devices with IP addresses in the infrastructure IP address range: !-- Note: IPC packets sent to UDP destination port 1975 must not !-- be permitted from any trusted source as this traffic !-- should only be sent and received internally by the !-- affected device using an IP address allocated from the !-- 127.0.0.0/8 prefix. !-- !-- IPC that traffic that is internally generated and sent !-- and/or received by the affected device is not subjected !-- to packet filtering by the applied iACL policy. ! !-- Deny IPC (UDP port 1975) packets from all sources destined to !-- all IP addresses configured on the affected device. ! access-list 150 deny udp any host INTERFACE_ADDRESS#1 eq 1975 access-list 150 deny udp any host INTERFACE_ADDRESS#2 eq 1975 access-list 150 deny udp any host INTERFACE_ADDRESS#N eq 1975 ! !-- Deny all IP packets with a source or destination IP address !-- from the 127.0.0.0/8 prefix. ! access-list 150 deny ip 127.0.0.0 0.255.255.255 any access-list 150 deny ip any 127.0.0.0 0.255.255.255 ! !-- Permit/deny all other Layer 3 and Layer 4 traffic in accordance !-- with existing security policies and configurations. ! !-- Permit all other traffic to transit the device. ! access-list 150 permit ip any any ! !-- Apply iACL to interfaces in the ingress direction. ! interface GigabitEthernet0/0 ip access-group 150 in ! Note: iACLs that filter UDP packets destined to port 1975 can be used to mitigate this vulnerability. However, UDP port 1975 is a registered port number that can be used by certain applications. Filtering all packets that are destined to UDP port 1975 may cause some applications to malfunction. Therefore, the iACL policy needs to explicitly deny UDP packets using a destination port of 1975 that are sent to any router interface IP addresses for affected devices, then permit and/or deny all other Layer 3 and Layer 4 traffic in accordance with existing security policies and configurations, and then permit all other traffic to transit the device. iACLs must be applied on all interfaces to be used effectively. Since the IPC channel uses addresses from the 127.0.0.0/8 range, it is also necessary to filter packets that are sourced from or destined to this range as provided in the preceding example. The white paper entitled "Protecting Your Core: Infrastructure Protection Access Control Lists" presents guidelines and recommended deployment techniques for infrastructure protection access lists. This white paper can be obtained here: http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a1a55.shtml Additional Mitigation Techniques +------------------------------- Additional mitigation techniques that can be deployed on Cisco devices within the network are available in the Cisco Applied Mitigation Bulletin companion document for this advisory, which is available at the following link: http://www.cisco.com/warp/public/707/cisco-amb-20080924-ipc-and-ubr.shtml 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. This vulnerability was found internally. 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-20080924-ipc.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-bulletins at lists.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 | | Initial | | 1.0 | 2008-Sep-24 | 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjaLcIACgkQ86n/Gc8U/uDLHwCeO1ZYLn/jMCO2qIX5cBhtLo46 uokAn1Q+dApUNnQOJY6Eh1cVegNVXg43 =jP+C -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 24 10:50:00 2008 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 24 Sep 2008 17:50:00 +0200 Subject: Cisco Security Advisory: Cisco IOS Software Layer 2 Tunneling Protocol (L2TP) Denial of Service Vulnerability Message-ID: <200809241750.l2tp@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco IOS Software Layer 2 Tunneling Protocol (L2TP) Denial of Service Vulnerability Advisory ID: cisco-sa-20080924-l2tp http://www.cisco.com/warp/public/707/cisco-sa-20080924-l2tp.shtml Revision 1.0 For Public Release 2008 September 24 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= A vulnerability exists in the Cisco IOS software implementation of Layer 2 Tunneling Protocol (L2TP), which affects limited Cisco IOS software releases. Several features enable the L2TP mgmt daemon process within Cisco IOS software, including but not limited to Layer 2 virtual private networks (L2VPN), Layer 2 Tunnel Protocol Version 3 (L2TPv3), Stack Group Bidding Protocol (SGBP) and Cisco Virtual Private Dial-Up Networks (VPDN). Once this process is enabled the device is vulnerable. This vulnerability will result in a reload of the device when processing a specially crafted L2TP packet. Cisco has released free software updates that address this vulnerability. Workarounds that mitigate this vulnerability are available. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20080924-l2tp.shtml Note: The September 24, 2008 IOS Advisory bundled publication includes twelve Security Advisories. Eleven of the advisories address vulnerabilities in Cisco's IOS software, and one advisory addresses vulnerabilities in Cisco Unified Communications Manager. Each Advisory lists the releases that correct the vulnerability described in the Advisory. Please reference the following software table to find a release that fixes all published IOS software Advisories as of September 24th, 2008: http://www.cisco.com/warp/public/707/cisco-sa-20080924-bundle.shtml Individual publication links are listed below: * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosips.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ssl.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sip.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-cucm.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-vpn.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-mfi.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ipc.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ubr.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-multicast.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sccp.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosfw.shtml Affected Products ================= All devices running affected versions of 12.2 or 12.4 Cisco IOS system software and that have a vulnerable configuration are affected by this vulnerability. Vulnerable Products +------------------ To determine if a device is vulnerable, first confirm that the device is running an affected version of 12.2 or 12.4 Cisco IOS system software. Then check for the process L2TP mgmt daemon running on the device. To determine the software version running on a Cisco product, log in to the device and issue the show version command to display the system banner. Cisco IOS software will identify itself as "Internetwork Operating System Software" or simply "IOS." On the next line of output, the image name will be displayed between parentheses, followed by "Version" and the IOS release name. Other Cisco devices will not have the show version command or will give different output. The following example identifies a Cisco product that is running Cisco IOS Software Release 12.4(11)T2: Router#show version Cisco IOS Software, 7200 Software (C7200-ADVSECURITYK9-M), Version 12.4(11)T2, RELEASE SOFTWARE (fc4) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2007 by Cisco Systems, Inc. Compiled Tue 01-May-07 04:19 by prod_rel_team Additional information on the Cisco IOS release naming conventions can be found in the document entitled "White Paper: Cisco IOS Reference Guide," which is available at http://www.cisco.com/warp/public/620/1.html To check if the process L2TP mgmt daemon is running on a device, log into the command line interface (CLI) and issue the command show processes | include L2TP . (NOTE: The command is case sensitive.) If the output returns a line with the process name L2TP mgmt daemon, the device is vulnerable. The following example shows a device running the L2TP mgmt daemon process: Router#show processes | include L2TP 158 Mwe 62590FE4 4 3 133322900/24000 0 L2TP mgmt daemon Router# The L2TP mgmt daemon is started by several different types of configurations that may be deployed in networks that leverage the L2TP protocol. If any of the following commands appear within a device's configuration, show running-config, then the device will have started the L2TP mgmt daemon and is vulnerable. * Device is configured with Virtual Private Dial-Up Networks (VPDN). The command vpdn enable will appear in the device configuration. * Device is configured for L2TP or L2TPv3 Client-Initiated VPDN Tunneling. The command pseudowire peer-ip-address vcid pw-class pw-class-name " appears in the device configuration. * Device is configured with Stack Group Bidding Protocol (SGBP). The command sgbp group group-name will appear in the device configuration. * A L2TP signaling template has been defined. The command l2tp-class l2tp-class name will appear in the device configuration. * Devices configured for Layer 2 Tunnel Protocol Version 3 The commands pseudowire-class pseudowire-class name and a successfully applied interface xconnect command will appear in the device configuration. Products Confirmed Not Vulnerable +-------------------------------- * Devices that are running Cisco IOS versions that are not explicitly listed in the software table below as vulnerable, are not affected. * Cisco IOS XR is not affected. * Cisco IOS XE is not affected. No other Cisco products are currently known to be affected by this vulnerability. Details ======= Documented in RFC2661, L2TP and RFC3931, L2TPv3 are protocols for tunneling network traffic between two peers over an existing network. A device running affected 12.2 and 12.4 versions of Cisco IOS and that has the L2TP mgmt daemon process running will reload when processing a specially crafted L2TP packet. Several features leverage the L2TP protocol and start the L2TP mgmt daemon within Cisco IOS. These features have been outlined in this advisory under the Vulnerable Products section. This vulnerability is documented in Cisco bug ID CSCsh48879 and Common Vulnerabilities and Exposures (CVE) identifier CVE-2008-3813 has been assigned to this vulnerability. Vulnerability Scoring Details ============================= Cisco has provided scores for the vulnerability 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 CSCsh48879 - Crafted L2TP packet triggers a device reload. CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of the vulnerability will result in a reload of the device. Repeated exploitation may result in an extended denial of service (DoS) condition. 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. Each row of the Cisco IOS software table (below) names a Cisco IOS 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 Repaired Releases | | Release | | |--------------+----------------------------------------------------| | Affected | | Recommended | | 12.0-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.0 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.1-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.1 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.2-Based | First Fixed Release | Release | | Releases | | | |--------------+-----------------------------------+----------------| | 12.2 | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2B | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2BC | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2BW | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2BX | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2BY | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2BZ | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2CX | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2CY | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2CZ | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2DA | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2DD | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2DX | 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.2IRB | 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.2IXG | 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 | | |--------------+-----------------------------------+----------------| | | Note: Releases prior to 12.2(37) | | | 12.2SE | SE are not vulnerable. First | 12.2(46)SE | | | fixed in 12.2(44)SE | | |--------------+-----------------------------------+----------------| | 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 | | |--------------+-----------------------------------+----------------| | | Note: Releases prior to 12.2(37) | | | 12.2SG | SG are not vulnerable. First | 12.2(46)SG1 | | | Fixed in 12.2(44)SG | | |--------------+-----------------------------------+----------------| | 12.2SGA | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2SL | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2SM | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2SO | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2SRA | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2SRB | 12.2(33)SRB1 | 12.2(33)SRB4 | |--------------+-----------------------------------+----------------| | 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.2SY | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2SZ | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2T | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2TPC | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XA | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XB | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XC | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XD | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XE | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XF | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XG | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XH | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XI | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XJ | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XK | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XL | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XM | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XN | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XNA | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XNB | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XO | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XQ | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XR | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XS | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XT | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2XU | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 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 | | |--------------+-----------------------------------+----------------| | 12.2YJ | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YK | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YL | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YM | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YN | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YO | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YP | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YQ | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YR | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YS | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YT | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YU | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YV | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YW | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YX | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YY | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2YZ | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2ZA | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2ZB | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2ZC | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2ZD | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2ZE | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2ZF | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2ZG | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2ZH | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2ZJ | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2ZL | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2ZP | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2ZU | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2ZX | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2ZY | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.2ZYA | Not Vulnerable | | |--------------+-----------------------------------+----------------| | Affected | | Recommended | | 12.3-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.3 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.4-Based | First Fixed Release | Release | | Releases | | | |--------------+-----------------------------------+----------------| | 12.4 | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4JA | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4JK | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4JL | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4JMA | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4JMB | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4JMC | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4JX | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4MD | Not Vulnerable | | |--------------+-----------------------------------+----------------| | | Note: Releases prior to 12.4(11) | | | 12.4MR | MR are not vulnerable. First | 12.4(19)MR | | | fixed in 12.4(16)MR | | |--------------+-----------------------------------+----------------| | | | 12.4(15)SW2; | | 12.4SW | 12.4(11)SW3 | Available on | | | | 28-SEP-08 | |--------------+-----------------------------------+----------------| | | Note: Releases prior to 12.4(11)T | | | 12.4T | are not vulnerable. First fixed | 12.4(15)T7 | | | in 12.4(15)T | | |--------------+-----------------------------------+----------------| | 12.4XA | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4XB | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4XC | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4XD | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4XE | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4XF | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4XG | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4XJ | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |--------------+-----------------------------------+----------------| | 12.4XK | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4XL | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4XM | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4XN | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4XP | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4XQ | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4XT | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4XV | Vulnerable; contact TAC | | |--------------+-----------------------------------+----------------| | 12.4XW | 12.4(11)XW1 | 12.4(11)XW9 | |--------------+-----------------------------------+----------------| | 12.4XY | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4XZ | Not Vulnerable | | |--------------+-----------------------------------+----------------| | 12.4YA | Not Vulnerable | | +-------------------------------------------------------------------+ Workarounds =========== The following workarounds have been identified for this vulnerability. Note: L2TP implementations will need to allow UDP 1701, from trusted addresses to infrastructure addresses. This does not provide for a full mitigation as the source addresses may be spoofed. Note: L2TPv3 over IP only implementations need to deny all UDP 1701 from anywhere to the infrastructure addresses. * Infrastructure Access Control Lists Although it is often difficult to block traffic that transits a network, it is possible to identify traffic that should never be allowed to target infrastructure devices and block that traffic at the border of networks. Infrastructure Access Control Lists (iACLs) are a network security best practice and should be considered as a long-term addition to good network security as well as a workaround for these specific vulnerabilities. The iACL example below should be included as part of the deployed infrastructure access-list which will protect all devices with IP addresses in the infrastructure IP address range: !--- Permit L2TP UDP 1701 packets from all trusted !--- sources destined to infrastructure addresses. !--- NOTE: This does not prevent spoofed attacks. !--- To be a full mitigation, no trusted source !--- addresses should be listed. !--- Omit this line if using a L2TPv3 over IP implementation only. access-list 150 permit udp TRUSTED_SOURCE_ADDRESSES MASK INFRASTRUCTURE_ADDRESSES MASK eq 1701 !--- Deny L2TP UDP 1701 packets from all !--- sources destined to infrastructure addresses. access-list 150 deny udp any INFRASTRUCTURE_ADDRESSES MASK eq 1701 !--- If using a L2TPv3 over IP implementation ensure to allow L2TPv3 access-list 150 permit 115 !--- Permit/deny all other Layer 3 and Layer 4 traffic in accordance !--- with existing security policies and configurations !--- Permit all other traffic to transit the device. access-list 150 permit ip any any !--- Apply access-list to all interfaces (only one example shown) interface serial 2/0 ip access-group 150 in The white paper entitled "Protecting Your Core: Infrastructure Protection Access Control Lists" presents guidelines and recommended deployment techniques for infrastructure protection access lists. This white paper can be obtained at the following link: http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a1a55.shtml * Control Plane Policing Control Plane Policing (CoPP) can be used to block L2TP access to the device. Cisco IOS software releases 12.0S, 12.2SX, 12.2S, 12.3T, 12.4, and 12.4T support the CoPP feature. CoPP can be configured on a device to protect the management and control planes and minimize the risk and effectiveness of direct infrastructure attacks by explicitly permitting only authorized traffic that is sent to infrastructure devices in accordance with existing security policies and configurations. The CoPP example below should be included as part of the deployed CoPP which will protect all devices with IP addresses in the infrastructure IP address range. !--- Deny all trusted source L2TP UDP traffic sent to all IP addresses !--- configured on all interfaces of the affected device so that it !--- will not be policed by the CoPP feature. !--- NOTE: This does not prevent spoofed attacks. !--- To be a full mitigation, no trusted source !--- addresses should be listed. !--- Omit this line if using an L2TPv3 over IP implementation only. access-list 111 deny udp TRUSTED_SOURCE_ADDRESSES MASK INFRASTRUCTURE_ADDRESSES MASK eq 1701 !--- Permit all L2TP UDP traffic sent to all IP addresses !--- configured on all interfaces of the affected device so that it !--- will be policed and dropped by the CoPP feature access-list 111 permit udp any INFRASTRUCTURE_ADDRESSES MASK eq 1701 !--- If using an L2TPv3 over IP implementation ensure not to drop L2TPv3 access-list 111 deny 115 !--- Permit (Police or Drop)/Deny (Allow) all other Layer3 and Layer4 !--- traffic in accordance with existing security policies and !--- configurations for traffic that is authorized to be sent !--- to infrastructure devices !--- Create a Class-Map for traffic to be policed by !--- the CoPP feature class-map match-all drop-l2tp-class match access-group 111 !--- Create a Policy-Map that will be applied to the !--- Control-Plane of the device. policy-map drop-l2tp-traffic class drop-l2tp-class drop !--- Apply the Policy-Map to the !--- Control-Plane of the device control-plane service-policy input drop-l2tp-traffic In the above CoPP example, the access control list entries (ACEs) that match the potential exploit packets with the "permit" action result in these packets being discarded by the policy-map "drop" function, while packets that match the "deny" action (not shown) are not affected by the policy-map drop function. Please note that the policy-map syntax is different in the 12.2S and 12.0S Cisco IOS trains: policy-map drop-l2tp-traffic class drop-l2tp-class police 32000 1500 1500 conform-action drop exceed-action drop Additional information on the configuration and use of the CoPP feature is available at the following link: http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html Additional mitigations that can be deployed on Cisco devices within the network are available in the Cisco Applied Mitigation Bulletin companion document for this advisory: http://www.cisco.com/warp/public/707/cisco-amb-20080924-l2tp.shtml 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. This vulnerability was found by Cisco through internal testing. 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-20080924-l2tp.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 | | Initial | | 1.0 | 2008-September-24 | 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjaLcgACgkQ86n/Gc8U/uC/CQCfcC70VVLkBqFMyqTqBh9mP0pu BY4AniOvIpCfu1wKu/Zz7USner4MTUnB =jfZd -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 24 10:50:00 2008 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 24 Sep 2008 17:50:00 +0200 Subject: Cisco Security Advisory: Cisco IOS MPLS Forwarding Infrastructure Denial of Service Vulnerability Message-ID: <200809241750.mfi@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco IOS MPLS Forwarding Infrastructure Denial of Service Vulnerability Advisory ID: cisco-sa-20080924-mfi http://www.cisco.com/warp/public/707/cisco-sa-20080924-mfi.shtml Revision 1.0 For Public Release 2008 September 24 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= Cisco IOS Software Multi Protocol Label Switching (MPLS) Forwarding Infrastructure (MFI) is vulnerable to a Denial of Service (DoS) attack from specially crafted packets. Only the MFI is affected by this vulnerability. Older Label Forwarding Information Base (LFIB) implementation, which is replaced by MFI, is 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-20080924-mfi.shtml NOTE: The September 24, 2008 IOS Advisory bundled publication includes twelve Security Advisories. Eleven of the advisories address vulnerabilities in Cisco's IOS software, and one advisory addresses vulnerabilities in Cisco Unified Communications Manager. Each Advisory lists the releases that correct the vulnerability described in the Advisory. Please reference the following software table to find a release that fixes all published IOS software Advisories as of September 24th, 2008: http://www.cisco.com/warp/public/707/cisco-sa-20080924-bundle.shtml Individual publication links are listed below: * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosips.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ssl.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sip.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-cucm.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-vpn.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ipc.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ubr.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-multicast.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sccp.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosfw.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-l2tp.shtml Affected Products ================= Devices that run Cisco IOS software (including those that support Cisco IOS Software Modularity) and support MFI are affected if they are configured for MPLS. Vulnerable Products +------------------ A device that runs Cisco IOS software and supports MFI will have mfi_ios in the output of the show subsys command. The following example shows output from a device that supports MFI: Router#show subsys name mfi_ios Class Version mfi_ios Protocol 1.000.001 Router# The following example shows output from a device that is configured for MPLS: Router#show mpls interface Interface IP Tunnel BGP Static Operational Ethernet0/0 Yes (ldp) No No No Yes Router# To determine the software running on a Cisco product, log in to the device and issue the "show version" command to display the system banner. Cisco IOS software will identify itself as "Internetwork Operating System Software" or simply "IOS". On the next line of output, the image name will be displayed between parentheses, followed by "Version" and the IOS release name. Other Cisco devices will not have the "show version" command or will give different output. The following example identifies a Cisco product that is running Cisco IOS release 12.4(11)T2: Router#show version Cisco IOS Software,7200 Software (C7200-ADVSECURITYK9-M), Version 12.4(11)T2, RELEASE SOFTWARE (fc4) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2007 by Cisco Systems, Inc. Compiled Tue 01-May-07 04:19 by prod_rel_team Additional information on the Cisco IOS release naming conventions can be found on the document entitled "White Paper: Cisco IOS Reference Guide", which is available at http://www.cisco.com/warp/public/620/1.html Products Confirmed Not Vulnerable +-------------------------------- Devices running Cisco IOS software versions that do not include MFI are not vulnerable. Devices that are not configured for MPLS are not vulnerable. Devices that are running Cisco IOS XR software are not vulnerable. No other Cisco products are currently known to be affected by these vulnerabilities. Details ======= In newer versions of Cisco IOS software, a new packet forwarding infrastructure was introduced to improve scalability and performance. This forwarding infrastructure, called MFI, is transparent to the user. MFI manages MPLS data structures used for forwarding and replaces the older implementation, Label Forwarding Information Base (LFIB). Cisco IOS MFI implementation is vulnerable to a DoS attack from specially crafted packets that are handled in the software path, including transit packets that are handled in the software path. Such packets can be sent from the local segment to the interfaces that are configured for MPLS or via tunnel interfaces that are configured for MPLS. To target a remote system in an MPLS network, an attacker needs to have access to the MPLS network through an MPLS-enabled interface. MPLS packets are dropped on interfaces that are not configured for MPLS. Devices that support MFI will have mfi_ios in the output of the show subsys command. Interfaces that are enabled for MPLS can be seen by the show mpls interface command. More information on MFI can be found at the following link: http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_lsc_removed.html This vulnerability is documented in the Cisco Bug ID CSCsk93241 and has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2008-3804. 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 CSCsk93241 - Chunk memory corruption on LFDp Input Proc CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of this vulnerability may result in the reload of the device, leading to a DoS condition. 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. Each row of the Cisco IOS software table (below) names a Cisco IOS 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 Repaired Releases | | Release | | |------------+------------------------------------------------------| | Affected | | Recommended | | 12.0-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.0 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.1-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.1 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.2-Based | First Fixed Release | Release | | Releases | | | |------------+--------------------------------------+---------------| | 12.2 | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2B | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2BC | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2BW | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2BX | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2BY | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2BZ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2CX | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2CY | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2CZ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2DA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2DD | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2DX | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2EW | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2EWA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2EX | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2EY | 12.2(44)EY; Available on 16-DEC-08 | | |------------+--------------------------------------+---------------| | 12.2EZ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2FX | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2FY | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2FZ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2IRB | 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.2IXG | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2JA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2JK | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2MB | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2MC | Not Vulnerable | | |------------+--------------------------------------+---------------| | | Releases prior to 12.2(22)S are not | | | | vulnerable. | | | | | 12.2(33)SB2; | | 12.2S | Release 12.2(22)S and later and | Available on | | | prior to 12.2(30)S are vulnerable, | 26-SEP-08 | | | | | | | release 12.2(30)S and later are not | | | | vulnerable | | |------------+--------------------------------------+---------------| | | 12.2(31)SB12 | 12.2(33)SB2; | | 12.2SB | | Available on | | | 12.2(33)SB | 26-SEP-08 | |------------+--------------------------------------+---------------| | | | 12.2(33)SB2; | | 12.2SBC | Vulnerable; first fixed in 12.2SB | Available on | | | | 26-SEP-08 | |------------+--------------------------------------+---------------| | 12.2SCA | 12.2(33)SCA1 | 12.2(33)SCA1 | |------------+--------------------------------------+---------------| | | 12.2(44)SE3; Available on 30-SEP-08 | | | 12.2SE | | 12.2(46)SE | | | 12.2(46)SE | | |------------+--------------------------------------+---------------| | 12.2SEA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2SEB | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2SEC | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2SED | Vulnerable; first fixed in 12.2SE | 12.2(46)SE | |------------+--------------------------------------+---------------| | 12.2SEE | Vulnerable; first fixed in 12.2SE | 12.2(46)SE | |------------+--------------------------------------+---------------| | 12.2SEF | Not Vulnerable | | |------------+--------------------------------------+---------------| | | Note: Releases prior to 12.2(25)SEG4 | | | 12.2SEG | are vulnerable, release 12.2(25)SEG4 | 12.2(25)SEG6 | | | and later are not vulnerable; | | |------------+--------------------------------------+---------------| | 12.2SG | 12.2(50)SG; Available on 24-NOV-08 | 12.2(46)SG1 | |------------+--------------------------------------+---------------| | 12.2SGA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2SL | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2SM | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2SO | Not Vulnerable | | |------------+--------------------------------------+---------------| | | | 12.2(33)SRB4 | | 12.2SRA | Vulnerable; first fixed in 12.2SRB | | | | | 12.2(33)SRC2 | |------------+--------------------------------------+---------------| | 12.2SRB | 12.2(33)SRB4 | 12.2(33)SRB4 | |------------+--------------------------------------+---------------| | 12.2SRC | 12.2(33)SRC1 | 12.2(33)SRC2 | |------------+--------------------------------------+---------------| | 12.2SU | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2SV | Vulnerable; contact TAC | | |------------+--------------------------------------+---------------| | 12.2SVA | Vulnerable; contact TAC | | |------------+--------------------------------------+---------------| | 12.2SVC | Vulnerable; contact TAC | | |------------+--------------------------------------+---------------| | 12.2SVD | Vulnerable; contact TAC | | |------------+--------------------------------------+---------------| | | Note: Releases prior to 12.2(25)SW4 | | | 12.2SW | are vulnerable, release 12.2(25)SW4 | 12.2(25)SW12 | | | and later are 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 | 12.2(33)SXH3 | 12.2(33)SXH3 | |------------+--------------------------------------+---------------| | 12.2SY | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2SZ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2T | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2TPC | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XB | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XC | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XD | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XE | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XF | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XG | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XH | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XI | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XJ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XK | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XL | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XM | Not Vulnerable | | |------------+--------------------------------------+---------------| | | | 12.2(33)SB2; | | | | Available on | | | | 26-SEP-08 | | 12.2XN | Vulnerable; first fixed in 12.2SB | | | | | 12.2(33)SRC2 | | | | | | | | 12.2(33)XNA2 | |------------+--------------------------------------+---------------| | 12.2XNA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XNB | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XO | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XQ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XR | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XS | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XT | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2XU | Not Vulnerable | | |------------+--------------------------------------+---------------| | 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 | | |------------+--------------------------------------+---------------| | 12.2YJ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YK | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YL | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YM | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YN | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YO | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YP | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YQ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YR | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YS | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YT | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YU | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YV | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YW | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YX | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YY | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2YZ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2ZA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2ZB | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2ZC | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2ZD | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2ZE | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2ZF | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2ZG | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2ZH | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2ZJ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2ZL | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2ZP | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2ZU | Not Vulnerable | | |------------+--------------------------------------+---------------| | | | 12.2(33)SB2; | | 12.2ZX | Vulnerable; first fixed in 12.2SB | Available on | | | | 26-SEP-08 | |------------+--------------------------------------+---------------| | 12.2ZY | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.2ZYA | Not Vulnerable | | |------------+--------------------------------------+---------------| | Affected | | Recommended | | 12.3-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.3 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.4-Based | First Fixed Release | Release | | Releases | | | |------------+--------------------------------------+---------------| | 12.4 | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JK | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JL | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JMA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JMB | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JMC | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4JX | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4MD | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4MR | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4SW | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4T | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XA | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XB | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XC | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XD | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XE | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XF | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XG | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XJ | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XK | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XL | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XM | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XN | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XP | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XQ | 12.4(15)XQ1 | 12.4(15)XQ1 | |------------+--------------------------------------+---------------| | 12.4XR | Vulnerable; migrate to any release | 12.4(15)T7 | | | in 12.4T | | |------------+--------------------------------------+---------------| | 12.4XT | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XV | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XW | Not Vulnerable | | |------------+--------------------------------------+---------------| | 12.4XY | 12.4(15)XY4 | 12.4(15)XY4 | |------------+--------------------------------------+---------------| | 12.4XZ | 12.4(15)XZ1 | 12.4(15)XZ2 | |------------+--------------------------------------+---------------| | 12.4YA | Not Vulnerable | | +-------------------------------------------------------------------+ Workarounds =========== MPLS is normally enabled on physical and logical interfaces that are shared with other MPLS-enabled devices. It can be disabled on interfaces where MPLS is not necessary and from which a potential attack can be launched. This action may help to limit the exposure of this vulnerability. If it is not possible to disable MPLS on interfaces from which an attack can be launched, there are no workarounds to mitigate this vulnerability. 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. This vulnerability was found internally. 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-20080924-mfi.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-bulletins at lists.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 | | Initial | | 1.0 | 2008-Sep-24 | 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjaLcwACgkQ86n/Gc8U/uCKtQCeOUTNVK58br0wqCUQAa506CGJ aWIAn3WBReM3lzWMM/+iT7SVaH6npY3E =7zu4 -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 24 10:50:00 2008 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 24 Sep 2008 17:50:00 +0200 Subject: Cisco Security Advisory: Multiple Multicast Vulnerabilities in Cisco IOS Software Message-ID: <200809241750.multicast@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Multiple Multicast Vulnerabilities in Cisco IOS Software Advisory ID: cisco-sa-20080924-multicast http://www.cisco.com/warp/public/707/cisco-sa-20080924-multicast.shtml Revision 1.0 For Public Release 2008 September 24 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= Two crafted Protocol Independent Multicast (PIM) packet vulnerabilities exist in Cisco IOS software that may lead to a denial of service (DoS) condition. Cisco has released free software updates that address these vulnerabilities. Workarounds that mitigate these vulnerabilities are available. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20080924-multicast.shtml Note: The September 24, 2008 IOS Advisory bundled publication includes twelve Security Advisories. Eleven of the advisories address vulnerabilities in Cisco's IOS software, and one advisory addresses vulnerabilities in Cisco Unified Communications Manager. Each Advisory lists the releases that correct the vulnerability described in the Advisory. Please reference the following software table to find a release that fixes all published IOS software Advisories as of September 24th, 2008: http://www.cisco.com/warp/public/707/cisco-sa-20080924-bundle.shtml Individual publication links are listed below: * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosips.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ssl.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sip.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-cucm.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-vpn.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-mfi.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ipc.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ubr.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sccp.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosfw.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-l2tp.shtml Affected Products ================= Vulnerable Products +------------------ Devices that are running Cisco IOS Software and configured for PIM have a vulnerability related to a specially crafted PIM packet. In addition, Cisco 12000 Series (GSR) routers running Cisco IOS Software have a second vulnerability related to a crafted PIM packet. The show running-config | include ip pim command can be issued to verify that a Cisco IOS device is configured for PIM. In the following example, the Cisco IOS router is configured for PIM sparse-dense mode. Router#show running-config | include ip pim ip pim sparse-dense-mode Note that available PIM modes on a Cisco IOS device are dense mode, sparse mode, or sparse-dense mode. A device that is configured for any of these modes is affected by these vulnerabilities. The mode determines how the device populates its multicast routing table and how multicast packets are forwarded. PIM must be enabled in one of these modes for an interface to perform IP multicast routing. More information on the configuration of each mode is in the "Details" section. Additionally, To display information about interfaces configured for Protocol Independent Multicast (PIM), use the show ip pim interface command in user EXEC or privileged EXEC mode, as shown in the following example: Router# show ip pim interface Address Interface Ver/ Nbr Query DR DR Mode Count Intvl Prior 10.1.0.1 GigabitEthernet0/0 v2/SD 0 30 1 10.1.0.1 10.6.0.1 GigabitEthernet0/1 v2/SD 1 30 1 10.6.0.2 In order to determine the software that runs on a Cisco IOS product, log in to the device and issue the show version command to display the system banner. Cisco IOS software identifies itself as "Internetwork Operating System Software" or simply "IOS." On the next line of output, the image name displays between parentheses, followed by "Version" and the Cisco IOS release name. Other Cisco devices do not have the show version command or give different output. The following example shows output from a device that runs an IOS image: router>show version Cisco IOS Software, 7200 Software (C7200-ADVSECURITYK9-M), Version 12.4(6)T2, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2006 by Cisco Systems, Inc. Compiled Tue 16-May-06 16:09 by kellythw Products Confirmed Not Vulnerable +-------------------------------- Cisco IOS devices that are not configured for PIM are not vulnerable. Cisco IOS XR Software is not affected by this vulnerability. No other Cisco products are currently known to be affected by this vulnerability. Details ======= Two crafted Protocol Independent Multicast (PIM) packet vulnerabilities exist in Cisco IOS Software that may lead to a denial of service (DoS) condition. Devices that run Cisco IOS Software and are configured for PIM are affected by the first vulnerability. Only Cisco 12000 Series (GSR) routers that are configured for PIM are affected by the second vulnerability. Available PIM modes on a Cisco IOS device are dense mode, sparse mode, or sparse-dense mode. The mode determines how the device populates its multicast routing table and how multicast packets are forwarded. PIM must be enabled in one of these modes for an interface to perform IP multicast routing. Note: There is no default mode setting. By default, multicast routing is disabled on an interface. To configure PIM on an interface to be in dense mode, use the following command in interface configuration mode: Router(config-if)# ip pim dense-mode To configure PIM on an interface to be in sparse mode, use the following command in interface configuration mode: Router(config-if)# ip pim sparse-mode To configure PIM on an interface to be in sparse-dense mode, use the following command in interface configuration mode: Router(config-if)# ip pim sparse-dense-mode These vulnerabilities are documented in the following Cisco Bug IDs: * CSCsd95616 - Crafted PIM packets may cause an IOS device to reload * CSCsl34355 - GSR may crash with malformed PIM packets These vulnerabilities have been assigned the Common Vulnerabilities and Exposures (CVE) identifiers CVE-2008-3808 and CVE-2008-3809. 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 CSCsd95616 - Crafted PIM packets may cause an IOS device to reload CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed CSCsl34355 - GSR may crash with malformed PIM packets CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation may cause a reload of the affected device. Repeated exploitation could result in a sustained denial of service (DoS) condition. 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. Each row of the Cisco IOS software table (below) names a Cisco IOS 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 Repaired Releases | | Release | | |------------+------------------------------------------------------| | Affected | | Recommended | | 12.0-Based | First Fixed Release | Release | | Releases | | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0 | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | Releases prior to 12.0(8)DA3 are | 12.2(12)DA13 | | | vulnerable, release 12.0(8)DA3 and | | | 12.0DA | later are not vulnerable; first fixed | 12.4(15)T7 | | | in 12.2DA | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0DB | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0DC | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | 12.0(32)S8 | 12.0(32)S11 | | 12.0S | | | | | 12.0(33)S | 12.0(33)S1 | |------------+---------------------------------------+--------------| | | | 12.0(32)S11 | | 12.0SC | Vulnerable; first fixed in 12.0S | | | | | 12.0(33)S1 | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0SL | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0SP | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.0(32)S11 | | 12.0ST | Vulnerable; first fixed in 12.0S | | | | | 12.0(33)S1 | |------------+---------------------------------------+--------------| | | | 12.0(32)S11 | | 12.0SX | Vulnerable; first fixed in 12.0S | | | | | 12.0(33)S1 | |------------+---------------------------------------+--------------| | | | 12.0(32)SY7; | | 12.0SY | 12.0(32)SY5 | Available on | | | | 29-SEP-08 | |------------+---------------------------------------+--------------| | | | 12.0(32)S11 | | 12.0SZ | 12.0(30)SZ4 | | | | | 12.0(33)S1 | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0T | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.0W | Vulnerable; first fixed in 12.2 | 12.0(3c)W5 | | | | (8) | |------------+---------------------------------------+--------------| | | Releases prior to 12.0(5)WC10 are | 12.4(15)T7 | | 12.0WC | vulnerable, release 12.0(5)WC10 and | | | | later are not vulnerable; first fixed | 12.4(18c) | | | in 12.2 | | |------------+---------------------------------------+--------------| | 12.0WT | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0XA | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0XB | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | Releases prior to 12.0(2)XC2 are | 12.4(15)T7 | | 12.0XC | vulnerable, release 12.0(2)XC2 and | | | | later are not vulnerable; first fixed | 12.4(18c) | | | in 12.2 | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0XD | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0XE | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.0XF | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0XG | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0XH | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | Releases prior to 12.0(4)XI2 are | 12.4(15)T7 | | 12.0XI | vulnerable, release 12.0(4)XI2 and | | | | later are not vulnerable; first fixed | 12.4(18c) | | | in 12.2 | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0XJ | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0XK | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0XL | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0XM | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0XN | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0XQ | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0XR | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.0XS | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0XT | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.0XV | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | Affected | | Recommended | | 12.1-Based | First Fixed Release | Release | | Releases | | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1 | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1AA | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.1AX | Vulnerable; first fixed in 12.2EY | 12.2(46)SE | |------------+---------------------------------------+--------------| | | Releases prior to 12.1(22)AY1 are | 12.1(22)EA12 | | 12.1AY | vulnerable, release 12.1(22)AY1 and | | | | later are not vulnerable; first fixed | 12.2(46)SE | | | in 12.1EA | | |------------+---------------------------------------+--------------| | 12.1AZ | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1CX | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.2(12)DA13 | | | | | | 12.1DA | Vulnerable; first fixed in 12.2DA | 12.4(15)T7 | | | | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1DB | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1DC | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.1E | 12.1(27b)E2 | 12.2(18) | | | | SXF15 | |------------+---------------------------------------+--------------| | 12.1EA | 12.1(22)EA10 | 12.1(22)EA12 | |------------+---------------------------------------+--------------| | 12.1EB | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | | | 12.2(33)SCA1 | | 12.1EC | Vulnerable; first fixed in 12.3BC | | | | | 12.3(23)BC4 | |------------+---------------------------------------+--------------| | 12.1EO | Vulnerable; first fixed in 12.2SV | | |------------+---------------------------------------+--------------| | | | 12.2(25) | | | | EWA14 | | 12.1EU | Vulnerable; first fixed in 12.2EWA | | | | | 12.2(31)SGA8 | | | | | | | | 12.2(46)SG1 | |------------+---------------------------------------+--------------| | 12.1EV | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.2(25) | | | | EWA14 | | | | | | | | 12.2(31)SGA8 | | 12.1EW | Vulnerable; first fixed in 12.2 | | | | | 12.2(46)SG1 | | | | | | | | 12.4(15)T7 | | | | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1EX | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.1EY | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | | | 12.2(18) | | | | SXF15 | | 12.1EZ | Vulnerable; first fixed in 12.1E | | | | | 12.4(15)T7 | | | | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1GA | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1GB | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1T | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XA | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XB | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XC | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XD | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XE | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XF | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XG | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XH | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XI | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XJ | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XL | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XM | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XP | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XQ | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XR | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XS | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XT | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XU | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XV | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XW | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XX | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XY | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1XZ | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1YA | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1YB | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1YC | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1YD | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | Releases prior to 12.1(5)YE6 are | 12.4(15)T7 | | 12.1YE | vulnerable, release 12.1(5)YE6 and | | | | later are not vulnerable; first fixed | 12.4(18c) | | | in 12.2 | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1YF | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.1YH | Vulnerable; first fixed in 12.2 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.1YI | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.1YJ | Not Vulnerable | | |------------+---------------------------------------+--------------| | Affected | | Recommended | | 12.2-Based | First Fixed Release | Release | | Releases | | | |------------+---------------------------------------+--------------| | | 12.2(26c) | | | | | | | | 12.2(27c) | | | | | 12.4(15)T7 | | 12.2 | 12.2(28d) | | | | | 12.4(18c) | | | 12.2(29b) | | | | | | | | 12.2(46) | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2B | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.2(33)SCA1 | | | | | | | | 12.3(23)BC4 | | 12.2BC | Vulnerable; first fixed in 12.3 | | | | | 12.4(15)T7 | | | | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2BW | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.2(33)SB2; | | | | Available on | | | | 26-SEP-08 | | 12.2BX | Vulnerable; first fixed in 12.3 | | | | | 12.4(15)T7 | | | | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2BY | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2BZ | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.2(33)SCA1 | | | | | | | | 12.3(23)BC4 | | 12.2CX | Vulnerable; first fixed in 12.3 | | | | | 12.4(15)T7 | | | | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.2(33)SCA1 | | | | | | | | 12.3(23)BC4 | | 12.2CY | Vulnerable; first fixed in 12.3 | | | | | 12.4(15)T7 | | | | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.2(33)SB2; | | 12.2CZ | Vulnerable; first fixed in 12.2S | Available on | | | | 26-SEP-08 | |------------+---------------------------------------+--------------| | | 12.2(10)DA9 | | | 12.2DA | | 12.2(12)DA13 | | | 12.2(12)DA13 | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2DD | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2DX | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.2(25) | | | | EWA14 | | 12.2EW | Vulnerable; first fixed in 12.2EWA | | | | | 12.2(31)SGA8 | | | | | | | | 12.2(46)SG1 | |------------+---------------------------------------+--------------| | | 12.2(25)EWA10 | 12.2(25) | | 12.2EWA | | EWA14 | | | 12.2(25)EWA11 | | |------------+---------------------------------------+--------------| | 12.2EX | 12.2(37)EX | 12.2(35)EX2 | |------------+---------------------------------------+--------------| | 12.2EY | 12.2(37)EY | | |------------+---------------------------------------+--------------| | 12.2EZ | Vulnerable; first fixed in 12.2SEE | 12.2(46)SE | |------------+---------------------------------------+--------------| | 12.2FX | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2FY | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2FZ | Vulnerable; first fixed in 12.2SE | 12.2(46)SE | |------------+---------------------------------------+--------------| | 12.2IRB | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2IXA | Vulnerable; migrate to any release in | 12.2(18)IXG | | | 12.2IXE | | |------------+---------------------------------------+--------------| | 12.2IXB | Vulnerable; migrate to any release in | 12.2(18)IXG | | | 12.2IXE | | |------------+---------------------------------------+--------------| | 12.2IXC | Vulnerable; migrate to any release in | 12.2(18)IXG | | | 12.2IXE | | |------------+---------------------------------------+--------------| | 12.2IXD | Vulnerable; migrate to any release in | 12.2(18)IXG | | | 12.2IXE | | |------------+---------------------------------------+--------------| | 12.2IXE | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2IXF | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2IXG | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2JA | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2JK | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.2(25)SW12 | | | | | | 12.2MB | Vulnerable; first fixed in 12.2SW | 12.4(15)T7 | | | | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2MC | 12.2(15)MC2i | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | 12.2(14)S18 | | | | | | | | 12.2(18)S13 | 12.2(33)SB2; | | 12.2S | | Available on | | | 12.2(20)S13 | 26-SEP-08 | | | | | | | 12.2(25)S13 | | |------------+---------------------------------------+--------------| | | 12.2(28)SB7 | | | | | 12.2(33)SB2; | | 12.2SB | 12.2(31)SB5 | Available on | | | | 26-SEP-08 | | | 12.2(33)SB | | |------------+---------------------------------------+--------------| | | | 12.2(33)SB2; | | 12.2SBC | Vulnerable; first fixed in 12.2SB | Available on | | | | 26-SEP-08 | |------------+---------------------------------------+--------------| | 12.2SCA | Not Vulnerable | | |------------+---------------------------------------+--------------| | | 12.2(35)SE4 | | | 12.2SE | | 12.2(46)SE | | | 12.2(37)SE | | |------------+---------------------------------------+--------------| | 12.2SEA | Vulnerable; first fixed in 12.2SEE | 12.2(46)SE | |------------+---------------------------------------+--------------| | 12.2SEB | Vulnerable; first fixed in 12.2SEE | 12.2(46)SE | |------------+---------------------------------------+--------------| | 12.2SEC | Vulnerable; first fixed in 12.2SEE | 12.2(46)SE | |------------+---------------------------------------+--------------| | 12.2SED | Vulnerable; first fixed in 12.2SEE | 12.2(46)SE | |------------+---------------------------------------+--------------| | 12.2SEE | 12.2(25)SEE4 | 12.2(46)SE | |------------+---------------------------------------+--------------| | 12.2SEF | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SEG | 12.2(25)SEG3 | 12.2(25)SEG6 | |------------+---------------------------------------+--------------| | | 12.2(25)SG3 | | | | | | | 12.2SG | 12.2(31)SG3 | 12.2(46)SG1 | | | | | | | 12.2(37)SG | | |------------+---------------------------------------+--------------| | 12.2SGA | 12.2(31)SGA2 | 12.2(31)SGA8 | |------------+---------------------------------------+--------------| | 12.2SL | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SM | 12.2(29)SM3 | 12.2(29)SM4 | |------------+---------------------------------------+--------------| | 12.2SO | Vulnerable; first fixed in 12.2SV | | |------------+---------------------------------------+--------------| | | | 12.2(33)SRB4 | | 12.2SRA | 12.2(33)SRA4 | | | | | 12.2(33)SRC2 | |------------+---------------------------------------+--------------| | 12.2SRB | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SRC | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2SU | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.2SV | 12.2(29b)SV1 | | |------------+---------------------------------------+--------------| | 12.2SVA | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SVC | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SVD | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SW | 12.2(25)SW12 | 12.2(25)SW12 | |------------+---------------------------------------+--------------| | 12.2SX | Vulnerable; first fixed in 12.2SXF | 12.2(18) | | | | SXF15 | |------------+---------------------------------------+--------------| | 12.2SXA | Vulnerable; first fixed in 12.2SXF | 12.2(18) | | | | SXF15 | |------------+---------------------------------------+--------------| | 12.2SXB | Vulnerable; first fixed in 12.2SXF | 12.2(18) | | | | SXF15 | |------------+---------------------------------------+--------------| | 12.2SXD | Vulnerable; first fixed in 12.2SXF | 12.2(18) | | | | SXF15 | |------------+---------------------------------------+--------------| | 12.2SXE | Vulnerable; first fixed in 12.2SXF | 12.2(18) | | | | SXF15 | |------------+---------------------------------------+--------------| | 12.2SXF | 12.2(18)SXF9 | 12.2(18) | | | | SXF15 | |------------+---------------------------------------+--------------| | | Not Vulnerable | | | 12.2SXH | | | | | http://www.cisco.com/go/pn | | |------------+---------------------------------------+--------------| | | | 12.2(33)SB2; | | 12.2SY | Vulnerable; first fixed in 12.2S | Available on | | | | 26-SEP-08 | |------------+---------------------------------------+--------------| | | | 12.2(33)SB2; | | 12.2SZ | Vulnerable; first fixed in 12.2S | Available on | | | | 26-SEP-08 | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2T | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.2TPC | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XA | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XB | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XC | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XD | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XE | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.2(33)SCA1 | | | | | | | | 12.3(23)BC4 | | 12.2XF | Vulnerable; first fixed in 12.3 | | | | | 12.4(15)T7 | | | | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | Releases prior to 12.2(2)XG1 are | 12.4(15)T7 | | 12.2XG | vulnerable, release 12.2(2)XG1 and | | | | later are not vulnerable; first fixed | 12.4(18c) | | | in 12.3 | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XH | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XI | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XJ | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XK | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XL | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XM | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.2(33)SB2; | | | | Available on | | | | 26-SEP-08 | | 12.2XN | 12.2(33)XN1 | | | | | 12.2(33)SRC2 | | | | | | | | 12.2(33)XNA2 | |------------+---------------------------------------+--------------| | 12.2XNA | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2XNB | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2XO | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XQ | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | Releases prior to 12.2(15)XR are | 12.3(8)JEA3 | | | vulnerable, release 12.2(15)XR and | | | 12.2XR | later are not vulnerable; first fixed | 12.4(15)T7 | | | in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XS | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XT | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XU | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XV | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XW | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2YA | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.2YB | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YC | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YD | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YE | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YF | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YG | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YH | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YJ | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YK | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YL | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2YM | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.2YN | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YO | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2YP | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.2YQ | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YR | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YS | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2YT | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YU | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YV | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YW | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YX | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YY | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YZ | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2ZA | Vulnerable; first fixed in 12.2SXF | 12.2(18) | | | | SXF15 | |------------+---------------------------------------+--------------| | 12.2ZB | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2ZC | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2ZD | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2ZE | Vulnerable; first fixed in 12.3 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2ZF | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2ZG | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2ZH | 12.2(13)ZH9 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.2ZJ | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2ZL | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2ZP | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2ZU | Vulnerable; migrate to any release in | 12.2(33)SXH3 | | | 12.2SXH | | |------------+---------------------------------------+--------------| | | | 12.2(33)SB2; | | 12.2ZX | Vulnerable; first fixed in 12.2SB | Available on | | | | 26-SEP-08 | |------------+---------------------------------------+--------------| | 12.2ZY | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2ZYA | Not Vulnerable | | |------------+---------------------------------------+--------------| | Affected | | Recommended | | 12.3-Based | First Fixed Release | Release | | Releases | | | |------------+---------------------------------------+--------------| | | 12.3(17c) | | | | | | | | 12.3(18a) | | | | | 12.4(15)T7 | | 12.3 | 12.3(19a) | | | | | 12.4(18c) | | | 12.3(20a) | | | | | | | | 12.3(21) | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3B | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | 12.3(17b)BC6 | | | 12.3BC | | 12.3(23)BC4 | | | 12.3(21)BC | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3BW | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 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 | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3T | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.3TPC | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.3VA | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XA | 12.3(2)XA7 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.3XB | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XC | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XD | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XE | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.3XF | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XG | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.2(33)SB2; | | 12.3XI | 12.3(7)XI10 | Available on | | | | 26-SEP-08 | |------------+---------------------------------------+--------------| | | | 12.3(14)YX13 | | 12.3XJ | Vulnerable; first fixed in 12.3YX | | | | | 12.4(15)T7 | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XK | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XL | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XQ | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XR | 12.3(7)XR7 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XS | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.3XU | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | | | 12.3(14)YX13 | | 12.3XW | Vulnerable; first fixed in 12.3YX | | | | | 12.4(15)T7 | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XX | 12.3(8)XX2d | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XY | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XZ | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3YA | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.3YD | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | | | 12.3(14)YX13 | | 12.3YF | Vulnerable; first fixed in 12.3YX | | | | | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.3YG | 12.3(8)YG6 | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.3YH | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.3YI | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.3YJ | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.3YK | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | | | 12.3(14) | | 12.3YM | 12.3(14)YM10 | YM13; | | | | Available on | | | | 30-SEP-08 | |------------+---------------------------------------+--------------| | 12.3YQ | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.3YS | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.3YT | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | | | 12.4(2)XB10 | | | | | | 12.3YU | Vulnerable; first fixed in 12.4XB | 12.4(9)XG3 | | | | | | | | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.3YX | 12.3(14)YX8 | 12.3(14)YX13 | |------------+---------------------------------------+--------------| | 12.3YZ | 12.3(11)YZ3 | | |------------+---------------------------------------+--------------| | 12.3ZA | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | Affected | | Recommended | | 12.4-Based | First Fixed Release | Release | | Releases | | | |------------+---------------------------------------+--------------| | | 12.4(10c) | | | | | | | | 12.4(12) | | | | | | | | 12.4(3h) | | | 12.4 | | 12.4(18c) | | | 12.4(5c) | | | | | | | | 12.4(7e) | | | | | | | | 12.4(8d) | | |------------+---------------------------------------+--------------| | 12.4JA | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4JK | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4JL | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4JMA | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4JMB | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4JMC | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4JX | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4MD | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4MR | 12.4(11)MR | 12.4(19)MR | |------------+---------------------------------------+--------------| | 12.4SW | Not Vulnerable | | |------------+---------------------------------------+--------------| | | 12.4(11)T | | | | | | | | 12.4(2)T6 | | | | | | | 12.4T | 12.4(4)T8 | 12.4(15)T7 | | | | | | | 12.4(6)T7 | | | | | | | | 12.4(9)T3 | | |------------+---------------------------------------+--------------| | 12.4XA | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.4XB | 12.4(2)XB6 | 12.4(2)XB10 | |------------+---------------------------------------+--------------| | 12.4XC | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | | | 12.4(4)XD11; | | 12.4XD | 12.4(4)XD8 | Available on | | | | 26-SEP-08 | |------------+---------------------------------------+--------------| | 12.4XE | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.4XF | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4XG | 12.4(9)XG2 | 12.4(9)XG3 | |------------+---------------------------------------+--------------| | 12.4XJ | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4XK | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4XL | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4XM | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4XN | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4XP | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.4XQ | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4XR | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4XT | 12.4(6)XT2 | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.4XV | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4XW | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4XY | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4XZ | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4YA | Not Vulnerable | | +-------------------------------------------------------------------+ Workarounds =========== Specifying trusted PIM neighbors is a workaround for both vulnerabilities. A PIM router must receive PIM Hellos to establish PIM neighborship. PIM neighborship is also the basis for designated router (DR) election, DR failover, and accepting/sending PIM Join/ Prune/Assert messages. To specify trusted PIM neighbors, use the ip pim neighbor-filter command, as shown in the following example: Router(config)#access-list 1 permit host 10.10.10.123 !-- An access control list is created to allow a trusted PIM neighbor !-- in this example the neighbor is 10.10.10.123 ! Router(config)#interface fastEthernet 0/0 Router(config-if)#ip pim neighbor-filter 1 !-- The PIM neighbor filter is then applied to the respective interface(s) The ip pim neighbor-filter command filters PIM packets from untrusted devices including Hellos, Join/Prune, and BSR packets. Note: The vulnerabilities described in this document can be exploited by spoofed IP packets if the attacker knows the IP address of the trusted PIM neighbors listed in the ip pim neighbor-filter implementation. To protect infrastructure devices and minimize the risk, impact, and effectiveness of direct infrastructure attacks, administrators are advised to deploy ACLs to perform policy enforcement of traffic sent to core infrastructure equipment. PIM is IP protocol 103. As an additional workaround, administrators can explicitly permit only authorized PIM (IP protocol 103) traffic sent to infrastructure devices in accordance with existing security policies and configurations. An ACL can be deployed as shown in the following example: ip access-list extended Infrastructure-ACL-Policy ! !-- When applicable, include explicit permit statements for trusted !-- sources that require access on the vulnerable protocol !-- PIM routers need to communicate with the rendezvous point (RP). !-- In this example, 192.168.100.1 is the IP address of the !-- rendezvous point, which is a trusted host that requires access !-- to and from the affected PIM devices. ! permit pim host 192.168.100.1 192.168.60.0 0.0.0.255 permit pim 192.168.60.0 0.0.0.255 host 192.168.100.1 ! !-- Permit PIM segment traffic, packets have destination of: !-- 224.0.0.13 (PIMv2) !-- 224.0.0.2 (Required only by legacy PIMv1) ! permit pim 192.168.60.0 0.0.0.255 host 224.0.0.13 permit pim 192.168.60.0 0.0.0.255 host 224.0.0.2 ! !-- The following vulnerability-specific access control entries !-- (ACEs) can aid in identification of attacks ! deny pim any 192.168.60.0 0.0.0.255 ! !-- Explicit deny ACE for traffic sent to addresses configured within !-- the infrastructure address space ! deny ip any 192.168.60.0 0.0.0.255 ! !-- Permit/deny all other Layer 3 and Layer 4 traffic in accordance !-- with existing security policies and configurations ! !-- Apply iACL to interfaces in the ingress direction ! interface GigabitEthernet0/0 ip access-group Infrastructure-ACL-Policy in 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 vulnerabilities described in this advisory. These vulnerabilities were found during internal testing. 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-20080924-multicast.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-bulletins at lists.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 | | Initial | | 1.0 | 2008-September-24 | 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjaLdEACgkQ86n/Gc8U/uBLYQCfbFNaZROaq5OZX5KzZAVwv0gr oBwAoJeb3PdxAWcVg3sBKladJgqbb1oy =f4p/ -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 24 10:50:00 2008 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 24 Sep 2008 17:50:00 +0200 Subject: Cisco Security Advisory: Cisco IOS NAT Skinny Call Control Protocol Vulnerability Message-ID: <200809241750.sccp@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco IOS NAT Skinny Call Control Protocol Vulnerability Advisory ID: cisco-sa-20080924-sccp http://www.cisco.com/warp/public/707/cisco-sa-20080924-sccp.shtml Revision 1.0 For Public Release 2008 September 24 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= A series of segmented Skinny Call Control Protocol (SCCP) messages may cause a Cisco IOS device that is configured with the Network Address Translation (NAT) SCCP Fragmentation Support feature to reload. Cisco has released free software updates that address this vulnerability. A workaround that mitigates this vulnerability is available. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20080924-sccp.shtml Note: The September 24, 2008 IOS Advisory bundled publication includes twelve Security Advisories. Eleven of the advisories address vulnerabilities in Cisco's IOS software, and one advisory addresses vulnerabilities in Cisco Unified Communications Manager. Each Advisory lists the releases that correct the vulnerability described in the Advisory. Please reference the following software table to find a release that fixes all published IOS software Advisories as of September 24th, 2008: http://www.cisco.com/warp/public/707/cisco-sa-20080924-bundle.shtml Individual publication links are listed below: * http://www.cisco.com/warp/public/707/cisco-sa-20080924-cucm.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosfw.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosips.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ipc.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-l2tp.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-mfi.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-multicast.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sccp.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sip.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ssl.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ubr.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-vpn.shtml Affected Products ================= Vulnerable Products +------------------ This security advisory applies to all Cisco products that run Cisco IOS Software configured for NAT and that support the NAT SCCP Fragmentation Support feature. This feature was first introduced in Cisco IOS version 12.4(6)T. To verify if NAT is enabled on a Cisco IOS device log into the device and issue the command show ip nat statistics. The following example shows a device configured with NAT: Router# show ip nat statistics Total translations: 2 (0 static, 2 dynamic; 0 extended) Outside interfaces: Serial0 Inside interfaces: Ethernet1 Hits: 135 Misses: 5 Expired translations: 2 Dynamic mappings: -- Inside Source access-list 1 pool mypool refcount 2 pool mypool: netmask 255.255.255.0 start 192.168.10.1 end 192.168.10.254 type generic, total addresses 14, allocated 2 (14%), misses 0 Alternatively, you can use the show running-config | include ip nat command to verify if NAT has been enabled on the router interfaces. Note: With reference to NAT, the term "inside" refers to those networks that will be translated. Inside this domain, hosts will have addresses in one address space, while on the "outside", they will appear to have addresses in another address space when NAT is configured. The first address space is referred to as the local address space and the second is referred to as the global address space. The ip nat inside and ip nat outside interface commands must be present on the corresponding router interfaces in order for NAT to be enabled. In order to determine the software that runs on a Cisco IOS product, log in to the device and issue the show version command to display the system banner. Cisco IOS software identifies itself as "Internetwork Operating System Software" or simply "IOS." On the next line of output, the image name displays between parentheses, followed by "Version" and the Cisco IOS release name. Other Cisco devices do not have the show version command or give different output. The following example shows output from a device that runs an IOS image: router>show version Cisco IOS Software, 7200 Software (C7200-ADVSECURITYK9-M), Version 12.4(6)T2, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2006 by Cisco Systems, Inc. Compiled Tue 16-May-06 16:09 by kellythw Products Confirmed Not Vulnerable +-------------------------------- Cisco IOS XR and IOS XE are not affected by this vulnerability. Cisco IOS devices not explicitly configured for NAT are not vulnerable. No other Cisco products are currently known to be affected by these vulnerabilities. Details ======= The Skinny Call Control Protocol (SCCP) enables voice communication between an SCCP client and a Call Manager (CM). Typically, the CM provides service to the SCCP clients on TCP Port 2000 by default. Initially, an SCCP client connects to the CM by establishing a TCP connection; the client will also establish a TCP connection with a secondary CM, if available. The NAT SCCP Fragmentation Support feature prevents skinny control message exchanges from failing in a TCP segmentation scenario because the NAT Skinny Application Layer Gateway (ALG) is able to reassemble the skinny control messages. A segmented payload that requires an IP or port translation will no longer be dropped. The NAT SCCP Fragmentation Support feature was introduced in Cisco IOS version 12.4(6)T. A series of fragmented SCCP messages may cause a Cisco IOS router that is running the NAT SCCP Fragmentation Support feature to reload. This vulnerability is documented in Cisco Bug ID CSCsg22426 and CSCsi17020, and has been assigned CVE identifiers CVE-2008-3810 and CVE-2008-3811. 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 CSCsg22426 - Cisco IOS Skinny Call Control Protocol (SCCP) Vulnerability CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed CSCsi17020 - Router may reload after NAT with certain skinny packets CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of this vulnerability may cause the affected device to reload. Repeated exploitation will result in a denial of service (DoS) condition. 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. Each row of the Cisco IOS software table (below) names a Cisco IOS 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 Release | Availability of Repaired Releases | |-------------------+-----------------------------------------------| | Affected | | | | 12.0-Based | First Fixed Release | Recommended Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.0 based releases | |-------------------------------------------------------------------| | Affected | | | | 12.1-Based | First Fixed Release | Recommended Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.1 based releases | |-------------------------------------------------------------------| | Affected | | | | 12.2-Based | First Fixed Release | Recommended Release | | Releases | | | |-------------------+-----------------------+-----------------------| | 12.2 | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2B | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2BC | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2BW | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2BX | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2BY | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2BZ | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2CX | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2CY | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2CZ | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2DA | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2DD | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2DX | 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.2IRB | 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.2IXG | 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 | | |-------------------+-----------------------+-----------------------| | | Not Vulnerable | | | 12.2SXH | | | | | http://www.cisco.com/ | | | | go/pn | | |-------------------+-----------------------+-----------------------| | 12.2SY | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2SZ | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2T | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2TPC | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XA | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XB | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XC | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XD | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XE | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XF | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XG | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XH | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XI | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XJ | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XK | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XL | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XM | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XN | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XNA | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XNB | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XO | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XQ | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XR | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XS | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XT | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2XU | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 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 | | |-------------------+-----------------------+-----------------------| | 12.2YJ | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YK | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YL | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YM | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YN | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YO | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YP | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YQ | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YR | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YS | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YT | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YU | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YV | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YW | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YX | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YY | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2YZ | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2ZA | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2ZB | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2ZC | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2ZD | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2ZE | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2ZF | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2ZG | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2ZH | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2ZJ | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2ZL | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2ZP | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2ZU | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2ZX | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2ZY | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.2ZYA | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | Affected | | | | 12.3-Based | First Fixed Release | Recommended Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.3 based releases | |-------------------------------------------------------------------| | Affected | | | | 12.4-Based | First Fixed Release | Recommended Release | | Releases | | | |-------------------+-----------------------+-----------------------| | 12.4 | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4JA | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4JK | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4JL | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4JMA | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4JMB | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4JMC | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4JX | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4MD | 12.4(11)MD4 | 12.4(15)MD1 | |-------------------+-----------------------+-----------------------| | 12.4MR | 12.4(16)MR | 12.4(19)MR | |-------------------+-----------------------+-----------------------| | | 12.4(15)SW2; | 12.4(15)SW2; | | 12.4SW | Available on | Available on | | | 28-SEP-08 | 28-SEP-08 | |-------------------+-----------------------+-----------------------| | | 12.4(11)T4 | | | | | | | | 12.4(15)T2 | | | | | | | 12.4T | 12.4(20)T | 12.4(15)T7 | | | | | | | 12.4(6)T11 | | | | | | | | 12.4(9)T5 | | |-------------------+-----------------------+-----------------------| | 12.4XA | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4XB | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4XC | Vulnerable; first | 12.4(15)T7 | | | fixed in 12.4T | | |-------------------+-----------------------+-----------------------| | 12.4XD | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4XE | Vulnerable; first | 12.4(15)T7 | | | fixed in 12.4T | | |-------------------+-----------------------+-----------------------| | 12.4XF | Vulnerable; first | 12.4(15)T7 | | | fixed in 12.4T | | |-------------------+-----------------------+-----------------------| | 12.4XG | 12.4(9)XG3 | 12.4(9)XG3 | |-------------------+-----------------------+-----------------------| | 12.4XJ | Vulnerable; first | 12.4(15)T7 | | | fixed in 12.4T | | |-------------------+-----------------------+-----------------------| | 12.4XK | Vulnerable; first | 12.4(15)T7 | | | fixed in 12.4T | | |-------------------+-----------------------+-----------------------| | 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.4XP | Vulnerable; contact | | | | TAC | | |-------------------+-----------------------+-----------------------| | 12.4XQ | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4XR | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4XT | Vulnerable; first | 12.4(15)T7 | | | fixed in 12.4T | | |-------------------+-----------------------+-----------------------| | 12.4XV | Vulnerable; contact | | | | TAC | | |-------------------+-----------------------+-----------------------| | 12.4XW | 12.4(11)XW7 | 12.4(11)XW9 | |-------------------+-----------------------+-----------------------| | 12.4XY | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4XZ | Not Vulnerable | | |-------------------+-----------------------+-----------------------| | 12.4YA | Not Vulnerable | | +-------------------------------------------------------------------+ Workarounds =========== As workaround, an administrator can disable SCCP NAT support using the no ip nat service skinny tcp port 2000 command, as shown in the following example: Router(config)# no ip nat service skinny tcp port 2000 Note: If your Cisco CallManager is using a TCP port for skinny signaling different from the default port (2000), you need to adjust this command accordingly. 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. 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-20080924-sccp.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 | | Initial | | 1.0 | 2008-September-24 | 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjaLdUACgkQ86n/Gc8U/uBM1ACeMzZ03zyWQhMRkiHOGUi20KeT NAoAnR9OVAOw7st0mwFWyEmatcQIxy2v =CqpX -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 24 10:50:00 2008 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 24 Sep 2008 17:50:00 +0200 Subject: Cisco Security Advisory: Vulnerability in Cisco IOS While Processing SSL Packet Message-ID: <200809241750.ssl@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Vulnerability in Cisco IOS While Processing SSL Packet Advisory ID: cisco-sa-20080924-ssl http://www.cisco.com/warp/public/707/cisco-sa-20080924-ssl.shtml Revision 1.0 For Public Release 2008 September 24 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= A Cisco IOS device may crash while processing an SSL packet. This can happen during the termination of an SSL-based session. The offending packet is not malformed and is normally received as part of the packet exchange. Cisco has released free software updates that address this vulnerability. Aside from disabling affected services, there are no available workarounds to mitigate an exploit of this vulnerability. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20080924-ssl.shtml Note: The September 24, 2008 IOS Advisory bundled publication includes twelve Security Advisories. Eleven of the advisories address vulnerabilities in Cisco's IOS software, and one advisory addresses vulnerabilities in Cisco Unified Communications Manager. Each Advisory lists the releases that correct the vulnerability described in the Advisory. Please reference the following software table to find a release that fixes all published IOS software Advisories as of September 24th, 2008: http://www.cisco.com/warp/public/707/cisco-sa-20080924-bundle.shtml Individual publication links are listed below: * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosips.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sip.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-cucm.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-vpn.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-mfi.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ipc.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ubr.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-multicast.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sccp.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosfw.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-l2tp.shtml Affected Products ================= Vulnerable Products +------------------ Devices running Cisco IOS and using SSL-based services are susceptible to this vulnerability. Some of the services that utilize SSL are: * HTTP server supporting SSL encryption (HTTPS) The following example shows a device that has the standard Cisco IOS HTTP server disabled, but the SSL-enabled Cisco IOS HTTP server enabled: Router#show running-config | include ip http no ip http server ip http secure-server Router# * SSL Virtual Private Network (SSL VPN) also known as AnyConnect VPN The following example shows a device that has the SSL VPN feature enabled: Router#show running-config | include webvpn webvpn enable webvpn Router# * Open Settlement Protocol (OSP) for Packet Telephony feature The following example shows a device that has the OSP feature enabled and uses HTTPS protocol that is vulnerable: Router#show running-config | include url url https://:443/ Router# The Cisco IOS Bug Toolkit may not accurately reflect the affected releases for this advisory. The affected releases are as follows: * 12.4(16)MR, 12.4(16)MR1, 12.4(16)MR2 * 12.4(17) To determine the version of the Cisco IOS software running on a Cisco product, log in to the device and issue the show version command to display the system banner. Cisco IOS Software will identify itself as "Internetwork Operating System Software" or simply "IOS." On the next line of output, the image name will be displayed between parentheses, followed by "Version" and the IOS release name. Other Cisco devices will not have the show version command or will give different output. Router#show version Cisco IOS Software, 1841 Software (C1841-ADVSECURITYK9-M), Version 12.4(15)T2, RELEASE SOFTWARE (fc7) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by Cisco Systems, Inc. Compiled Thu 17-Jan-08 23:12 by prod_rel_team Additional information about Cisco IOS software release naming is available at the following link: http://www.cisco.com/warp/public/620/1.html Products Confirmed Not Vulnerable +-------------------------------- No other Cisco products and Cisco IOS releases are currently known to be affected by this vulnerability. Details ======= This vulnerability is triggered during the termination of an SSL session. Possession of valid credentials such as a username, password or a certificate is not required. SSL protocol uses TCP as a transport protocol. The requirement of the complete TCP 3-way handshake reduces the probability that this vulnerability will be exploited through the use of spoofed IP addresses. A device running vulnerable Cisco IOS Software with SSL-based service configured will crash while terminating an SSL session. This vulnerability is documented in Cisco Bug ID CSCsj85065 and has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2008-3798. 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 CSCsj85065 - Router reload while processing SSL packets CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== A successful exploit of this vulnerability may cause a crash of the affected device. Repeated exploitation may result in a sustained denial of service condition. 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. Each row of the Cisco IOS software table (below) names a Cisco IOS 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 Release | Availability of Repaired Releases | |---------------------------+---------------------------------------| | Affected 12.0-Based | First Fixed | Recommended | | Releases | Release | Release | |-------------------------------------------------------------------| | There are no affected 12.0 based releases | |-------------------------------------------------------------------| | Affected 12.1-Based | First Fixed | Recommended | | Releases | Release | Release | |-------------------------------------------------------------------| | There are no affected 12.1 based releases | |-------------------------------------------------------------------| | Affected 12.2-Based | First Fixed | Recommended | | Releases | Release | Release | |-------------------------------------------------------------------| | There are no affected 12.2 based releases | |-------------------------------------------------------------------| | Affected 12.3-Based | First Fixed | Recommended | | Releases | Release | Release | |-------------------------------------------------------------------| | There are no affected 12.3 based releases | |-------------------------------------------------------------------| | Affected 12.4-Based | First Fixed | Recommended | | Releases | Release | Release | |---------------------------+-------------------+-------------------| | | 12.4(17a) | | | 12.4 | | 12.4(18c) | | | 12.4(18) | | |---------------------------+-------------------+-------------------| | 12.4JA | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4JK | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4JL | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4JMA | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4JMB | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4JMC | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4JX | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4MD | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4MR | 12.4(19)MR | 12.4(19)MR | |---------------------------+-------------------+-------------------| | 12.4SW | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4T | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XA | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XB | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XC | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XD | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XE | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XF | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XG | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XJ | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XK | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XL | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XM | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XN | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XP | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XQ | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XT | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XV | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XW | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XY | Not Vulnerable | | |---------------------------+-------------------+-------------------| | 12.4XZ | Not Vulnerable | | +-------------------------------------------------------------------+ Workarounds =========== To prevent an exploit of a vulnerable device, SSL-based services need to be disabled. However, if regular maintenance and operation of the device relies on this service, there is no workaround. The following command will disable the vulnerable HTTPS service: Router(config)#no ip http secure-server The following command will disable the vulnerable SSL VPN service: Router(config)#no webvpn enable The following command will disable the vulnerable OSP service: Router(config)#no settlement Another option is to revert to HTTP protocol instead using HTTPS. The downside of this workaround is that the settlement information will be sent over the network unprotected. It is possible to mitigate this vulnerability by preventing unauthorized hosts from accessing affected devices. Control Plane Policing (CoPP) +---------------------------- Cisco IOS software versions that support Control Plane Policing (CoPP) can be configured to help protect the device from attacks that target the management and control planes. CoPP is available in Cisco IOS release trains 12.0S, 12.2SX, 12.2S, 12.3T, 12.4, and 12.4T. In the following CoPP example, the ACL entries that match the exploit packets with the permit action will be discarded by the policy-map drop function, whereas packets that match a deny action (not shown) are not affected by the policy-map drop function: !-- Include deny statements up front for any protocols/ports/IP addresses that !-- should not be impacted by CoPP !-- Include permit statements for the protocols/ports that will be !-- governed by CoPPaccess-list 100 permit tcp any any eq 443 !-- Permit (Police or Drop)/Deny (Allow) all other Layer3 and Layer4 !-- traffic in accordance with existing security policies and !-- configurations for traffic that is authorized to be sent !-- to infrastructure devices. ! !-- Create a Class-Map for traffic to be policed by !-- the CoPP feature. ! class-map match-all drop-SSL-class match access-group 100 ! !-- Create a Policy-Map that will be applied to the !-- Control-Plane of the device. ! policy-map drop-SSL-policy class drop-SSL-class drop !-- Apply the Policy-Map to the Control-Plane of the !-- device. ! control-plane service-policy input drop-SSL-policy Note: In the preceding CoPP example, the ACL entries with the permit action that match the exploit packets will result in the discarding of those packets by the policy-map drop function, whereas packets that match the deny action are not affected by the policy-map drop function. Additional information on the configuration and use of the CoPP feature is available at the following links: http://www.cisco.com/en/US/products/ps6642/products_white_paper0900aecd804fa16a.shtml and http://www.cisco.com/en/US/products/sw/iosswrel/ps1838/products_feature_guide09186a008052446b.html Access Control List (ACL) +------------------------ An Access Control List (ACL) can be used to help mitigate attacks that target this vulnerability. ACLs can specify that only packets from legitimate sources are permitted to reach a device, and all others are to be dropped. The following example shows how to allow legitimate SSL sessions from trusted sources and deny all other SSL sessions: access-list 101 permit tcp host host eq 443 access-list 101 deny tcp any any eq 443 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. 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-20080924-ssl.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-bulletins at lists.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 | | Initial | | 1.0 | 2008-September-24 | 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 - --------------------------------------------------------------------- Toolbar Contacts & Feedback | Help | Site Map 2007 - 2008 Cisco Systems, Inc. All rights reserved. Terms & Conditions | Privacy Statement | Cookie Policy | Trademarks of Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjaLeIACgkQ86n/Gc8U/uDvigCfcWXjj9bLlpN4XB1nMsDRt2h6 F5EAnRsZsoyb0638vZK7pU8owyw+Ust5 =gXdE -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 24 10:50:00 2008 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 24 Sep 2008 17:50:00 +0200 Subject: Cisco Security Advisory: Multiple Cisco IOS Session Initiation Protocol Denial of Service Vulnerabilities Message-ID: <200809241750.sip@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Multiple Cisco IOS Session Initiation Protocol Denial of Service Vulnerabilities Advisory ID: cisco-sa-20080924-sip http://www.cisco.com/warp/public/707/cisco-sa-20080924-sip.shtml Revision 1.0 For Public Release 2008 September 24 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= Multiple vulnerabilities exist in the Session Initiation Protocol (SIP) implementation in Cisco IOS that can be exploited remotely to trigger a memory leak or to cause a reload of the IOS device. Cisco has released free software updates that address these vulnerabilities. Fixed Cisco IOS software listed in the Software Versions and Fixes section contains fixes for all vulnerabilities addressed in this advisory. There are no workarounds available to mitigate the effects of any of the vulnerabilities apart from disabling the protocol or feature itself, if administrators do not require the Cisco IOS device to provide voice over IP services. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20080924-sip.shtml Note: The September 24, 2008 IOS Advisory bundled publication includes twelve Security Advisories. Eleven of the advisories address vulnerabilities in Cisco's IOS software, and one advisory addresses vulnerabilities in Cisco Unified Communications Manager. Each Advisory lists the releases that correct the vulnerability described in the Advisory. Please reference the following software table to find a release that fixes all published IOS software Advisories as of September 24th, 2008: http://www.cisco.com/warp/public/707/cisco-sa-20080924-bundle.shtml Individual publication links are listed below: * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosips.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ssl.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-cucm.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-vpn.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-mfi.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ipc.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ubr.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-multicast.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sccp.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosfw.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-l2tp.shtml Affected Products ================= These vulnerabilities only affect devices running Cisco IOS that have SIP voice services enabled. Vulnerable Products +------------------ Cisco devices running affected Cisco IOS versions and that may process SIP messages are affected. The only requirement for these vulnerabilities is that the Cisco IOS device processes SIP messages as part of configured voice over IP (VoIP) functionality (this does not apply to processing of SIP messages as part of the NAT and firewall feature sets.) Recent versions of Cisco IOS do not process SIP messages by default, but creating a "dial peer" via the command dial-peer voice will start the SIP processes and cause Cisco IOS to start processing SIP messages. An example of an affected configuration is as follows: dial-peer voice voip ... ! Note that older versions of Cisco IOS were affected by a bug that caused Cisco IOS to process SIP messages even without being configured for SIP operation. Please refer to http://www.cisco.com/warp/public/707/cisco-sa-20070131-sip.shtml for additional information on Cisco bug ID CSCsb25337. In addition to inspecting the Cisco IOS device configuration for a dial-peer command that causes the device to process SIP messages, administrators can also use some show commands to determine if the Cisco IOS device is running processes that handle SIP messages, or if the device is listening on the SIP ports. The command show processes | include SIP can be used to determine whether Cisco IOS is running the processes that handle SIP messages. In the following example, the presence of the processes CCSIP_UDP_SOCKET and CCSIP_TCP_SOCKET indicates that the Cisco IOS device is processing SIP messages: Router#show processes | include SIP 147 Mwe 40F46DF4 12 2 600023468/24000 0 CCSIP_SPI_CONTRO 148 Mwe 40F21244 0 1 0 5524/6000 0 CCSIP_DNS 149 Mwe 40F48254 4 1 400023108/24000 0 CCSIP_UDP_SOCKET 150 Mwe 40F48034 4 1 400023388/24000 0 CCSIP_TCP_SOCKET Different versions of Cisco IOS have different ways of verifying whether the Cisco IOS device is listening for SIP messages. The show ip sockets, show udp, show tcp brief all, and show control-plane host open-ports commands can be used to determine this, although not all of these commands work on all IOS releases. Since it is not practical in this document to provide a list of commands corresponding to the various releases, users should try the aforementioned commands to determine which ones work for their device. The following is one example of one command that shows a router listening on port 5060 (the SIP port): router#show control-plane host open-ports Active internet connections (servers and established) Prot Local Address Foreign Address Service State tcp *:5060 *:0 SIP LISTEN udp *:5060 *:0 SIP LISTEN In order to determine the software that runs on a Cisco IOS product, log in to the device and issue the show version command to display the system banner. Cisco IOS software identifies itself as "Internetwork Operating System Software" or simply "IOS." On the next line of output, the image name displays between parentheses, followed by "Version" and the Cisco IOS release name. Other Cisco devices do not have the show version command or give different output. The following example shows output from a device that runs an IOS image: router>show version Cisco IOS Software, 7200 Software (C7200-ADVSECURITYK9-M), Version 12.4(6)T2, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2006 by Cisco Systems, Inc. Compiled Tue 16-May-06 16:09 by kellythw Additional information on the Cisco IOS release naming conventions can be found on the document entitled "White Paper: Cisco IOS Reference Guide", which is available at http://www.cisco.com/warp/public/620/1.html Cisco Unified Communications Manager is also affected by some of these vulnerabilities, although they are tracked by different Cisco bug IDs. A companion security advisory for Cisco Unified Communications Manager is available at http://www.cisco.com/warp/public/707/cisco-sa-20080924-cucm.shtml Products Confirmed Not Vulnerable +-------------------------------- The SIP Application Layer Gateway (ALG), which is used by the IOS Network Address Translation (NAT) and firewall features of Cisco IOS, is not affected by these vulnerabilities. Cisco devices that are running Cisco IOS XR are not affected. With the exception of the Cisco Unified Communications Manager, no other Cisco products are currently known to be vulnerable to the issues described in this advisory. Details ======= SIP is a popular signaling protocol used to manage voice and video calls across IP networks such as the Internet. SIP is responsible for handling all aspects of call setup and termination. Voice and video are the most popular types of sessions that SIP handles, but the protocol is flexible to accommodate for other applications that require call setup and termination. SIP call signaling can use UDP (port 5060), TCP (port 5060), or TLS (TCP port 5061) as the underlying transport protocol. Multiple denial of service vulnerabilities exist in the SIP implementation in Cisco IOS. In all cases vulnerabilities can be triggered by processing valid SIP messages. Memory Leak Vulnerability +------------------------ CSCse56800 causes a memory leak in affected devices. The memory leak is caused by the processing of a specific type of valid SIP messages and may eventually disrupt the availability of all voice services, even if the Cisco IOS device is still running. This vulnerability has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2008-3799. Device Reload Vulnerabilities +---------------------------- The following vulnerabilities can lead to a reload of the Cisco IOS device while processing some specific and valid SIP messages: * CSCsg91306, assigned CVE ID CVE-2008-3800 * CSCsl62609, assigned CVE ID CVE-2008-3801 * CSCsk42759, assigned CVE ID CVE-2008-3802 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 CSCse56800 - SIP-3-BADPAIR register timer expiry causes slow memory leak CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed CSCsg91306 - processor pool memory corruption in CCSIP_SPI_CONTROL CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed CSCsk42759 - Voice Gateway reloads on receiving a valid SIP packet CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed CSCsl62609 - Router crash due to presence of valid SIP header CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of the vulnerabilities described in this document may result in a reload of the device. The issue could be repeatedly exploited to result in an extended Denial Of Service (DoS) condition. 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. Each row of the Cisco IOS software table (below) names a Cisco IOS 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 Repaired Releases | | Release | | |------------+------------------------------------------------------| | Affected | | Recommended | | 12.0-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.0 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.1-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.1 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.2-Based | First Fixed Release | Release | | Releases | | | |------------+---------------------------------------+--------------| | 12.2 | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2B | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.2BC | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2BW | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.2(33)SB2; | | | | Available on | | | | 26-SEP-08 | | 12.2BX | Vulnerable; first fixed in 12.4 | | | | | 12.4(15)T7 | | | | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2BY | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.2BZ | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2CX | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2CY | Not Vulnerable | | |------------+---------------------------------------+--------------| | | Vulnerable; migrate to any release in | 12.2(33)SB2; | | 12.2CZ | 12.2S | Available on | | | | 26-SEP-08 | |------------+---------------------------------------+--------------| | 12.2DA | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2DD | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2DX | 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.2IRB | 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.2IXG | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2JA | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2JK | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2MB | Not Vulnerable | | |------------+---------------------------------------+--------------| | | Releases prior to 12.2(15)MC2c are | 12.4(15)T7 | | 12.2MC | vulnerable, release 12.2(15)MC2c and | | | | later are not vulnerable; first fixed | 12.4(18c) | | | in 12.4 | | |------------+---------------------------------------+--------------| | 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.2SY | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2SZ | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2T | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.2TPC | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2XA | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XB | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.2XC | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2XD | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2XE | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2XF | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2XG | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2XH | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2XI | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2XJ | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2XK | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2XL | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XM | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.2XN | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2XNA | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2XNB | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2XO | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2XQ | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2XR | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2XS | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XT | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XU | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.2XV | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2XW | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2YA | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.2YB | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YC | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YD | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YE | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2YF | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YG | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2YH | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YJ | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YK | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2YL | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2YM | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.2YN | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YO | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2YP | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2YQ | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2YR | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2YS | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2YT | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YU | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | | Releases prior to 12.2(11)YV1 are | | | 12.2YV | vulnerable, release 12.2(11)YV1 and | | | | later are not vulnerable; | | |------------+---------------------------------------+--------------| | 12.2YW | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YX | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2YY | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2YZ | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2ZA | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2ZB | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2ZC | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2ZD | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2ZE | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2ZF | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.2ZG | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.2ZH | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.2ZJ | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2ZL | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2ZP | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.2ZU | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2ZX | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2ZY | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.2ZYA | Not Vulnerable | | |------------+---------------------------------------+--------------| | Affected | | Recommended | | 12.3-Based | First Fixed Release | Release | | Releases | | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3 | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3B | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.3BC | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.3BW | Not Vulnerable | | |------------+---------------------------------------+--------------| | 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 | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3T | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.3TPC | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.3VA | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | | Releases prior to 12.3(2)XA7 are | 12.4(15)T7 | | 12.3XA | vulnerable, release 12.3(2)XA7 and | | | | later are not vulnerable; first fixed | 12.4(18c) | | | in 12.4 | | |------------+---------------------------------------+--------------| | 12.3XB | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XC | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XD | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XE | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.3XF | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XG | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | Vulnerable; migrate to any release in | 12.2(33)SB2; | | 12.3XI | 12.2SB | Available on | | | | 26-SEP-08 | |------------+---------------------------------------+--------------| | | | 12.3(14)YX13 | | 12.3XJ | Vulnerable; first fixed in 12.3YX | | | | | 12.4(15)T7 | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XK | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XL | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XQ | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XR | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.3XS | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.3XU | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | | | 12.3(14)YX13 | | 12.3XW | Vulnerable; first fixed in 12.3YX | | | | | 12.4(15)T7 | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XX | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XY | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | | | 12.4(15)T7 | | 12.3XZ | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |------------+---------------------------------------+--------------| | 12.3YA | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.3YD | Not Vulnerable | | |------------+---------------------------------------+--------------| | | | 12.3(14)YX13 | | 12.3YF | Vulnerable; first fixed in 12.3YX | | | | | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.3YG | 12.3(8)YG7; Available on 01-OCT-08 | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.3YH | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.3YI | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.3YJ | Not Vulnerable | | |------------+---------------------------------------+--------------| | | Releases prior to 12.3(11)YK3 are | | | 12.3YK | vulnerable, release 12.3(11)YK3 and | 12.4(15)T7 | | | later are not vulnerable; first fixed | | | | in 12.4T | | |------------+---------------------------------------+--------------| | | | 12.3(14) | | 12.3YM | 12.3(14)YM13; Available on 30-SEP-08 | YM13; | | | | Available on | | | | 30-SEP-08 | |------------+---------------------------------------+--------------| | 12.3YQ | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.3YS | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.3YT | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | | | 12.4(2)XB10 | | | | | | 12.3YU | Vulnerable; first fixed in 12.4XB | 12.4(9)XG3 | | | | | | | | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.3YX | 12.3(14)YX12 | 12.3(14)YX13 | |------------+---------------------------------------+--------------| | 12.3YZ | 12.3(11)YZ3 | | |------------+---------------------------------------+--------------| | 12.3ZA | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | Affected | | Recommended | | 12.4-Based | First Fixed Release | Release | | Releases | | | |------------+---------------------------------------+--------------| | | 12.4(13f) | | | | | | | 12.4 | 12.4(17b) | 12.4(18c) | | | | | | | 12.4(18) | | |------------+---------------------------------------+--------------| | 12.4JA | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4JK | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4JL | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4JMA | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4JMB | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4JMC | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4JX | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4MD | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4MR | 12.4(19)MR | 12.4(19)MR | |------------+---------------------------------------+--------------| | 12.4SW | Not Vulnerable | | |------------+---------------------------------------+--------------| | | 12.4(15)T4 | | | | | | | 12.4T | 12.4(20)T | 12.4(15)T7 | | | | | | | 12.4(6)T11 | | |------------+---------------------------------------+--------------| | 12.4XA | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.4XB | 12.4(2)XB10 | 12.4(2)XB10 | |------------+---------------------------------------+--------------| | 12.4XC | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | | | 12.4(4)XD11; | | 12.4XD | 12.4(4)XD11; Available on 26-SEP-08 | Available on | | | | 26-SEP-08 | |------------+---------------------------------------+--------------| | 12.4XE | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.4XF | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4XG | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4XJ | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.4XK | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4XL | 12.4(15)XL2 | 12.4(15)XL2 | |------------+---------------------------------------+--------------| | 12.4XM | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4XN | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4XP | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.4XQ | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4XR | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4XT | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |------------+---------------------------------------+--------------| | 12.4XV | Vulnerable; contact TAC | | |------------+---------------------------------------+--------------| | 12.4XW | 12.4(11)XW7 | 12.4(11)XW9 | |------------+---------------------------------------+--------------| | 12.4XY | 12.4(15)XY3 | 12.4(15)XY4 | |------------+---------------------------------------+--------------| | 12.4XZ | Not Vulnerable | | |------------+---------------------------------------+--------------| | 12.4YA | Not Vulnerable | | +-------------------------------------------------------------------+ Workarounds =========== If the affected Cisco IOS device needs to provide voice over IP services and therefore SIP cannot be disabled then none of the listed vulnerabilities have workarounds. Users are advised to apply mitigation techniques to limit exposure to the listed vulnerabilities. Mitigation consists of only allowing legitimate devices to connect to the routers. To increase effectiveness, the mitigation must be coupled with anti-spoofing measures on the network edge. This action is required because SIP can use UDP as the transport protocol. Additional mitigations that can be deployed on Cisco devices within the network are available in the Cisco Applied Mitigation Bulletin companion document for this advisory, which is available at the following link: http://www.cisco.com/warp/public/707/cisco-amb-20080924-sip.shtml Disable SIP Listening Ports +-------------------------- For devices that do not require SIP to be enabled, the simplest and most effective workaround is to disable SIP processing on the device. Some versions of Cisco IOS allow administrators to accomplish this with the following commands: sip-ua no transport udp no transport tcp Warning: When applying this workaround to devices processing MGCP or H.323 calls, the device will not allow you to stop SIP processing while active calls are being processed. Under these circumstances, this workaround should be implemented during a maintenance window when active calls can be briefly stopped. It is recommended that after applying this workaround, the show commands discussed in the Vulnerable Products section be used to confirm that the Cisco IOS device is no longer processing SIP messages. Control Plane Policing +--------------------- For devices that need to offer SIP services it is possible to use Control Plane Policing (CoPP) to block SIP traffic to the device from untrusted sources. Cisco IOS software releases 12.0S, 12.2SX, 12.2S, 12.3T, 12.4, and 12.4T support the CoPP feature. CoPP may be configured on a device to protect the management and control planes to minimize the risk and effectiveness of direct infrastructure attacks by explicitly permitting only authorized traffic sent to infrastructure devices in accordance with existing security policies and configurations. The following example can be adapted to your network: !-- The 192.168.1.0/24 network and the 172.16.1.1 host are trusted. !-- Everything else is not trusted. The following access list is used !-- to determine what traffic needs to be dropped by a control plane !-- policy (the CoPP feature.) If the access list matches (permit) !-- then traffic will be dropped and if the access list does not !-- match (deny) then traffic will be processed by the router. access-list 100 deny udp 192.168.1.0 0.0.0.255 any eq 5060 access-list 100 deny tcp 192.168.1.0 0.0.0.255 any eq 5060 access-list 100 deny tcp 192.168.1.0 0.0.0.255 any eq 5061 access-list 100 deny udp host 172.16.1.1 any eq 5060 access-list 100 deny tcp host 172.16.1.1 any eq 5060 access-list 100 deny tcp host 172.16.1.1 any eq 5061 access-list 100 permit udp any any eq 5060 access-list 100 permit tcp any any eq 5060 access-list 100 permit tcp any any eq 5061 !-- Permit (Police or Drop)/Deny (Allow) all other Layer3 and Layer4 !-- traffic in accordance with existing security policies and !-- configurations for traffic that is authorized to be sent !-- to infrastructure devices. !-- Create a Class-Map for traffic to be policed by !-- the CoPP feature. class-map match-all drop-sip-class match access-group 100 !-- Create a Policy-Map that will be applied to the !-- Control-Plane of the device. policy-map drop-sip-traffic class drop-sip-class drop !-- Apply the Policy-Map to the Control-Plane of the !-- device. control-plane service-policy input drop-sip-traffic Warning: Because SIP can utilize UDP as a transport protocol, it is possible to easily spoof the sender's IP address, which may defeat ACLs that permit communication to these ports from trusted IP addresses. In the above CoPP example, the access control list entries (ACEs) that match the potential exploit packets with the "permit" action result in these packets being discarded by the policy-map "drop" function, while packets that match the "deny" action (not shown) are not affected by the policy-map drop function. Additional information on the configuration and use of the CoPP feature can be found at http://www.cisco.com/en/US/products/ps6642/products_white_paper0900aecd804fa16a.shtml and http://www.cisco.com/en/US/products/sw/iosswrel/ps1838/products_feature_guide09186a008052446b.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. These vulnerabilities were discovered by Cisco internal testing and during handling of customer service requests. 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-20080924-sip.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-bulletins at lists.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 | | Initial | | 1.0 | 2008-September-24 | 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjaLd0ACgkQ86n/Gc8U/uDWJwCdHEe8XwtX0kKmTHf2T6/Nm02U 3N8AnjG1IaW/GWg78gj6k0NGXre3Mggr =4nzw -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 24 10:50:00 2008 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 24 Sep 2008 17:50:00 +0200 Subject: Cisco Security Advisory: Cisco uBR10012 Series Devices SNMP Vulnerability Message-ID: <200809241750.ubr@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco uBR10012 Series Devices SNMP Vulnerability Advisory ID: cisco-sa-20080924-ubr http://www.cisco.com/warp/public/707/cisco-sa-20080924-ubr.shtml Revision 1.0 For Public Release 2008 September 24 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= Cisco uBR10012 series devices automatically enable Simple Network Management Protocol (SNMP) read/write access to the device if configured for linecard redundancy. This can be exploited by an attacker to gain complete control of the device. Only Cisco uBR10012 series devices that are configured for linecard redundancy are affected. Cisco has released free software updates that address this vulnerability. Workarounds that mitigate this vulnerability are available. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20080924-ubr.shtml NOTE: The September 24, 2008 IOS Advisory bundled publication includes twelve Security Advisories. Eleven of the advisories address vulnerabilities in Cisco's IOS^ software, and one advisory addresses vulnerabilities in Cisco Unified Communications Manager. Each Advisory lists the releases that correct the vulnerability described in the Advisory. Please reference the following software table to find a release that fixes all published IOS software Advisories as of September 24th, 2008: http://www.cisco.com/warp/public/707/cisco-sa-20080924-bundle.shtml Individual publication links are listed below: * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosips.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ssl.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sip.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-cucm.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-vpn.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-mfi.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ipc.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ubr.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-multicast.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sccp.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosfw.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-l2tp.shtml Affected Products ================= Vulnerable Products +------------------ Cisco uBR10012 series devices that are running Cisco IOS and configured for linecard redundancy are affected. Cisco uBR10012 series devices can be identified by issuing the show version command. The following example shows output from a Cisco uBR10012 series device running Cisco IOS software release 12.3(17b)BC7: ubr10k#show version | include IOS IOS (tm) 10000 Software (UBR10K-K8P6U2-M), Version 12.3(17b)BC7, RELEASE SOFTWARE (fc1) ubr10k# Please refer to the document entitled "White Paper: Cisco IOS Reference Guide" for additional information on the Cisco IOS release naming conventions. This document is available at the following link: http://www.cisco.com/warp/public/620/1.html A Cisco uBR10012 series device configured for linecard redundancy will have a line similar to the following in the output of show running-config command: member subslot / working or hccp protect Any version of Cisco IOS prior to the versions listed in the Software Versions and Fixes section below is vulnerable. Products Confirmed Not Vulnerable +-------------------------------- Cisco uBR10012 series devices that are not configured for linecard redundancy are not affected. Cisco 10000 series devices are not affected even if they are configured for linecard redundancy. Other uBR platforms are not affected. No other Cisco products are currently known to be affected by this vulnerability. Details ======= Cisco uBR10012 series devices need to communicate with an RF Switch when configured for linecard redundancy. This communication is based on SNMP (Simple Network Management Protocol). When linecard redundancy is enabled on a Cisco uBR10012 series device, SNMP is also automatically enabled with a default community string of private that has read/write privileges. Since there are no access restrictions on this community string, it may be exploited by an attacker to gain complete control of the device. Changing the default community string, adding access restrictions on SNMP or doing both will mitigate this vulnerability. The recommended mitigation is to do both. This vulnerability is documented in the Cisco Bug ID CSCek57932 and has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2008-3807. 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 CSCek57932 - SNMP enabled after redundancy is configured CVSS Base Score - 10 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - Complete Integrity Impact - Complete Availability Impact - Complete CVSS Temporal Score - 8.3 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of the vulnerability may allow an attacker to gain complete control of the device. 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. Each row of the Cisco IOS software table (below) names a Cisco IOS 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 Release | Availability of Repaired Releases | |--------------------+----------------------------------------------| | Affected | | Recommended | | 12.0-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.0 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.1-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.1 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.2-Based | First Fixed Release | Release | | Releases | | | |--------------------+------------------------------+---------------| | 12.2 | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2B | Not Vulnerable | | |--------------------+------------------------------+---------------| | | | 12.2(33)SCA1 | | | | | | | Vulnerable; migrate to any | 12.3(23)BC4 | | 12.2BC | release in 12.3 | | | | | 12.4(15)T7 | | | | | | | | 12.4(18c) | |--------------------+------------------------------+---------------| | 12.2BW | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2BX | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2BY | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2BZ | Not Vulnerable | | |--------------------+------------------------------+---------------| | | | 12.2(33)SCA1 | | | | | | | Vulnerable; migrate to any | 12.3(23)BC4 | | 12.2CX | release in 12.3 | | | | | 12.4(15)T7 | | | | | | | | 12.4(18c) | |--------------------+------------------------------+---------------| | | | 12.2(33)SCA1 | | | | | | | Vulnerable; migrate to any | 12.3(23)BC4 | | 12.2CY | release in 12.3 | | | | | 12.4(15)T7 | | | | | | | | 12.4(18c) | |--------------------+------------------------------+---------------| | 12.2CZ | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2DA | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2DD | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2DX | 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.2IRB | 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.2IXG | 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.2SY | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2SZ | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2T | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2TPC | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XA | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XB | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XC | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XD | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XE | Not Vulnerable | | |--------------------+------------------------------+---------------| | | | 12.2(33)SCA1 | | | | | | | Vulnerable; migrate to any | 12.3(23)BC4 | | 12.2XF | release in 12.3 | | | | | 12.4(15)T7 | | | | | | | | 12.4(18c) | |--------------------+------------------------------+---------------| | 12.2XG | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XH | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XI | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XJ | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XK | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XL | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XM | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XN | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XNA | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XNB | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XO | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XQ | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XR | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XS | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XT | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2XU | Not Vulnerable | | |--------------------+------------------------------+---------------| | 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 | | |--------------------+------------------------------+---------------| | 12.2YJ | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YK | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YL | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YM | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YN | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YO | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YP | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YQ | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YR | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YS | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YT | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YU | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YV | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YW | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YX | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YY | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2YZ | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2ZA | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2ZB | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2ZC | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2ZD | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2ZE | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2ZF | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2ZG | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2ZH | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2ZJ | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2ZL | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2ZP | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2ZU | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2ZX | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2ZY | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.2ZYA | Not Vulnerable | | |--------------------+------------------------------+---------------| | Affected | | Recommended | | 12.3-Based | First Fixed Release | Release | | Releases | | | |--------------------+------------------------------+---------------| | 12.3 | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3B | Not Vulnerable | | |--------------------+------------------------------+---------------| | | 12.3(17b)BC8 | | | 12.3BC | | 12.3(23)BC4 | | | 12.3(21)BC | | |--------------------+------------------------------+---------------| | 12.3BW | Not Vulnerable | | |--------------------+------------------------------+---------------| | 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 | | |--------------------+------------------------------+---------------| | 12.3T | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3TPC | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3VA | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XA | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XB | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XC | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XD | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XE | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XF | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XG | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XI | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XJ | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XK | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XL | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XQ | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XR | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XS | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XU | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XW | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XX | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XY | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3XZ | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3YA | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3YD | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3YF | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3YG | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3YH | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3YI | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3YJ | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3YK | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3YM | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3YQ | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3YS | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3YT | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3YU | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3YX | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3YZ | Not Vulnerable | | |--------------------+------------------------------+---------------| | 12.3ZA | Not Vulnerable | | |--------------------+------------------------------+---------------| | Affected | | Recommended | | 12.4-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.4 based releases | +-------------------------------------------------------------------+ Workarounds =========== Changing SNMP community string and restricting access +---------------------------------------------------- By default, Cisco uBR10012 series devices that are configured for linecard redundancy use a community string of private. This community string can be changed in Cisco IOS versions 12.3(13)BC and later. It is recommended to change the community string and apply access control restrictions that only permit authorized devices SNMP access to the device. The following configuration example provides operators with information on changing the community string and adding SNMP access control restrictions using an access control list (ACL). access-list 90 permit host access-list 90 permit host access-list 90 permit host access-list 90 deny any redundancy linecard-group 1 cable rf-switch snmp-community snmp-server community rw 90 When the SNMP community is changed on a Cisco uBR10012 device, is must also be changed on the RF Switch. It can be changed by the following command: set SNMP COMMUNITY If there is an up-converter in the network, the SNMP community used by the up-converter must also be changed after changing the community string on the Cisco uBR10012 device. Information on changing the community string used by the up-converter can be found at the following link: http://www.cisco.com/en/US/tech/tk86/tk804/technologies_tech_note09186a00801f7622.shtml#communication If the Cisco IOS version does not support changing the community string, access control restrictions can be applied to the default community string. The following configuration example provides operators with information on applying access control restrictions to the default community string. access-list 90 permit host access-list 90 permit host access-list 90 permit host access-list 90 deny any snmp-server community private rw 90 Using Infrastructure ACLs at Network Boundary +-------------------------------------------- Although it is often difficult to block traffic transiting your network, it is possible to identify traffic which should never be allowed to target your infrastructure devices and block that traffic at the border of your network. iACLs are a network security best practice and should be considered as a long-term addition to good network security as well as a workaround for this specific vulnerability. The iACL example shown below should be included as part of the deployed infrastructure access-list which will protect all devices with IP addresses in the infrastructure IP address range: !-- Permit SNMP (UDP port 161) packets from trusted hosts !-- destined to infrastructure addresses. ! access-list 150 permit udp TRUSTED_HOSTS MASK INFRASTRUCTURE_ADDRESSES MASK eq 161 ! !-- Deny SNMP (UDP port 161) packets from all other sources !-- destined to infrastructure addresses. ! access-list 150 deny udp any INFRASTRUCTURE_ADDRESSES MASK eq 161 ! !-- Permit/deny all other Layer 3 and Layer 4 traffic in !-- accordance with existing security policies and !-- configurations. ! !-- Permit all other traffic to transit the device. ! access-list 150 permit ip any any ! !-- Apply iACL to interfaces in the ingress direction. ! interface GigabitEthernet0/0 ip access-group 150 in ! The white paper entitled "Protecting Your Core: Infrastructure Protection Access Control Lists" presents guidelines and recommended deployment techniques for infrastructure protection access lists. This white paper can be obtained here: http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a1a55.shtml Additional Mitigation Techniques +------------------------------- Additional mitigation techniques that can be deployed on Cisco devices within the network are available in the Cisco Applied Mitigation Bulletin companion document for this advisory, which is available at the following link: http://www.cisco.com/warp/public/707/cisco-amb-20080924-ipc-and-ubr.shtml 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. This vulnerability was found internally. 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-20080924-ubr.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-bulletins at lists.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 | | Initial | | 1.0 | 2008-Sep-24 | 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjaLecACgkQ86n/Gc8U/uBcmQCggF37DyYthxIC+6vnZJesy8Cy hkAAnicMWS466BM5nAqpG6sDE9d3VTKo =iDxl -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 24 10:50:00 2008 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 24 Sep 2008 17:50:00 +0200 Subject: Cisco Security Advisory: Cisco Unified Communications Manager Session Initiation Protocol Denial of Service Vulnerabilities Message-ID: <200809241750.cucm@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco Unified Communications Manager Session Initiation Protocol Denial of Service Vulnerabilities Advisory ID: cisco-sa-20080924-cucm http://www.cisco.com/warp/public/707/cisco-sa-20080924-cucm.shtml Revision 1.0 For Public Release 2008 September 24 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= Cisco Unified Communications Manager, formerly Cisco Unified CallManager, contains two denial of service (DoS) vulnerabilities in the Session Initiation Protocol (SIP) service. An exploit of these vulnerabilities may cause an interruption in voice services. Cisco will release free software updates that address these vulnerabilities and this advisory will be updated as fixed software becomes available. There are no workarounds for these vulnerabilities. Note: Cisco IOS software is also affected by the vulnerabilities described in this advisory. A companion advisory for Cisco IOS software is available at http://www.cisco.com/warp/public/707/cisco-sa-20080924-sip.shtml This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20080924-cucm.shtml Affected Products ================= The vulnerabilities described in this document apply to the Cisco Unified Communications Manager. Vulnerable Products +------------------ The following Cisco Unified Communications Manager versions are affected: * Cisco Unified CallManager 4.1 versions prior to 4.1.3SR8 * Cisco Unified CallManager 4.2 versions prior to 4.2(3)SR4b * Cisco Unified CallManager 4.3 versions prior to 4.3(2)SR1a * Cisco Unified Communications Manager 5.x versions prior to 5.1 (3d) * Cisco Unified Communications Manager 6.x versions prior to 6.1(2) su1 Administrators of systems running Cisco Unified CallManager version 4.x can determine the software version by navigating to Help > About Cisco Unified CallManager and selecting the Details button via the Cisco Unified Communications Manager Administration interface. Administrators of systems that are running Cisco Unified Communications Manager versions 5.x and 6.x can determine the software version by viewing the main page of the Cisco Unified Communications Manager Administration interface. The software version can also be determined by running the command show version active via the command line interface. In Cisco Unified CallManager version 4.x, the use of SIP as a call signaling protocol is not enabled by default, and for the Cisco Unified CallManager server to start listening for SIP messages on TCP and UDP ports 5060 and 5061 a SIP trunk needs to be configured. In Cisco Unified Communications Manager versions 5.x and later, the use of SIP as a call signaling protocol is enabled by default in Cisco Unified Communications Manager and cannot be disabled. Cisco IOS software is also affected by these vulnerabilities, although they are tracked by different Cisco bug IDs. A companion security advisory for Cisco IOS software is available at http://www.cisco.com/warp/public/707/cisco-sa-20080924-sip.shtml Products Confirmed Not Vulnerable +-------------------------------- With the exception of Cisco IOS software, no other Cisco products are currently known to be vulnerable to the issues described in this advisory. Cisco Unified Communications Manager version 7.x is not affected by these vulnerabilities. Cisco Unified CallManager version 4.x is not affected by these vulnerabilities if it does not have any SIP trunks configured. Details ======= Cisco Unified Communications Manager is the call processing component of the Cisco IP Telephony solution that extends enterprise telephony features and functions to packet telephony network devices, such as IP phones, media processing devices, voice-over-IP gateways, and multimedia applications. SIP is a popular signaling protocol that is used to manage voice and video calls across IP networks such as the Internet. SIP is responsible for handling all aspects of call setup and termination. Voice and video are the most popular types of sessions that SIP handles, but the protocol is flexible to accommodate for other applications that require call setup and termination. SIP call signaling can use UDP (port 5060), TCP (port 5060), or TLS (TCP port 5061) as the underlying transport protocol. Two DoS vulnerabilities exist in the SIP implementation of the Cisco Unified Communications Manager. These vulnerabilities can be triggered while processing specific and valid SIP messages and can lead to a reload of the main Cisco Unified Communications Manager process. Version 4.x of Cisco Unified CallManager do not have SIP enabled by default unless a SIP trunk is configured. Versions 5.x and later of the Cisco Unified Communications Manager have SIP is enabled by default and cannot be disabled. The vulnerabilities are being tracked by the following Cisco bug IDs: * CSCsu38644, assigned CVE ID CVE-2008-3800 * CSCsm46064, assigned CVE ID CVE-2008-3801 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 CSCsu38644 - Valid SIP message can cause CCM process to crash CVSS Base Score - 7.1 Access Vector - Network Access Complexity - Medium Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 5.9 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed CSCsm46064 - Problem when CUCM sends out SIP message with valid header CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of the vulnerabilities described in this advisory may result in a reload of the Cisco Unified Communications Manager process, which could result in the interruption of voice services. 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 Unified CallManager version 4.1(3)SR8 contains fixes for all vulnerabilities affecting Cisco Unified CallManager version 4.1 listed in this advisory, and is scheduled to be released in early October 2008. Cisco Unified CallManager version 4.2(3)SR4b contains fixes for all vulnerabilities affecting Cisco Unified Communications Manager version 4.2.x listed in this advisory, and is scheduled to be released in early November 2008. Cisco Unified CallManager version 4.3(2)SR1a contains fixes for all vulnerabilities affecting Cisco Unified Communications Manager version 4.3.x listed in this advisory, and is scheduled to be released in early October 2008. Cisco Unified Communications Manager version 5.1(3d) contains fixes for all vulnerabilities affecting Cisco Unified Communications Manager version 5.x listed in this advisory, and is scheduled to be released in mid October 2008. Cisco Unified Communications Manager version 6.1(2)SU1 contains fixes for all vulnerabilities affecting Cisco Unified Communications Manager version 6.x listed in this advisory, and is scheduled to be released in mid October 2008. Downloading Cisco Unified Communications Manager Software +-------------------------------------------------------- To download Cisco Unified Communications Manager Software go to the Voice Software Downloads section of the Software Center on cisco.com at http://tools.cisco.com/support/downloads/go/Redirect.x?mdfid=278875240 then navigate to IP Telephony > Call Control > Cisco Unified Communications Manager (CallManager) and select the appropriate version of Cisco Unified Communications Manager. Workarounds =========== There are no workarounds for these vulnerabilities. It is possible to mitigate the vulnerabilities by implementing filtering on screening devices. Permit TCP/UDP access to ports 5060 and 5061 from only networks that need SIP access to Cisco Unified Communications Manager servers. If the Cisco Unified Communications Manager does not need to provide SIP services, the ports on which the Cisco Unified Communications Manager listens for SIP messages can be moved to non-standard ports. To change the ports from their default values, log into the Cisco Unified CallManager Administration web interface, go to System > Cisco Unified CM, locate the appropriate Cisco Unified Communications Manager, change the fields SIP Phone Port and SIP Phone Secure Port to a non-standard port, then click Save. SIP Phone Port, by default 5060, refers to the TCP and UDP ports where the Cisco Unified Communications Manager listens for normal SIP messages, and SIP Phone Secure Port, by default 5061, refers to the TCP and UDP ports where the Cisco Unified Communications Manager listens for SIP over TLS messages. For additional information about this procedure, refer to the "Updating a Cisco Unified Communications Manager" section of the "Cisco Unified Communications Manager Administration Guide" at http://www.cisco.com/en/US/docs/voice_ip_comm/cucmbe/admin/7_0_1/ccmcfg/b02ccm.html#wp1057513. Note: For a change of the SIP ports to take effect, the Cisco CallManager Service needs to be restarted. For information on how to accomplish this, refer to "Restarting the Cisco CallManager Service" at http://www.cisco.com/en/US/docs/voice_ip_comm/cucmbe/admin/7_0_1/ccmcfg/b03dpi.html#wp1075124 Additional mitigations that can be deployed on Cisco devices within the network are available in the Cisco Applied Mitigation Bulletin companion document for this advisory, which is available at the following link: http://www.cisco.com/warp/public/707/cisco-amb-20080924-sip.shtml 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. These vulnerabilities were discovered by Cisco internal testing and during handling of customer service requests. Status of this Notice: INTERIM ============================== 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. CISCO EXPECTS TO UPDATE THIS DOCUMENT AS NEW INFORMATION BECOMES AVAILABLE. 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-20080924-cucm.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-bulletins at lists.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 | | Initial | | 1.0 | 2008-September-24 | 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjaR1gACgkQ86n/Gc8U/uCAAQCfW5xFaGdt0C6ubIIW2kVj37Ak znYAn12eZ9BJNa4m6ia6Di1o+CQ4FAr3 =0Yk+ -----END PGP SIGNATURE----- From psirt at cisco.com Wed Sep 24 10:50:00 2008 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Wed, 24 Sep 2008 17:50:00 +0200 Subject: Cisco Security Advisory: Cisco IOS MPLS VPN May Leak Information Message-ID: <200809241750.vpn@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco IOS MPLS VPN May Leak Information Advisory ID: cisco-sa-20080924-vpn http://www.cisco.com/warp/public/707/cisco-sa-20080924-vpn.shtml Revision 1.0 For Public Release 2008 September 24 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= Devices running Cisco IOS versions 12.0S, 12.2, 12.3 or 12.4 and configured for Multiprotocol Label Switching (MPLS) Virtual Private Networks (VPNs) or VPN Routing and Forwarding Lite (VRF Lite) and using Border Gateway Protocol (BGP) between Customer Edge (CE) and Provider Edge (PE) devices may permit information to propagate between VPNs. Workarounds are available to help mitigate this vulnerability. This issue is triggered by a logic error when processing extended communities on the PE device. This issue cannot be deterministically exploited by an attacker. Cisco has released free software updates that address these vulnerabilities. Workarounds that mitigate these vulnerabilities are available. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20080924-vpn.shtml NOTE: The September 24, 2008 IOS Advisory bundled publication includes twelve Security Advisories. Eleven of the advisories address vulnerabilities in Cisco's IOS software, and one advisory addresses vulnerabilities in Cisco Unified Communications Manager. Each Advisory lists the releases that correct the vulnerability described in the Advisory. Please reference the following software table to find a release that fixes all published IOS software Advisories as of September 24th, 2008: http://www.cisco.com/warp/public/707/cisco-sa-20080924-bundle.shtml Individual publication links are listed below: * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosips.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ssl.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sip.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-cucm.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-mfi.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ipc.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-ubr.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-multicast.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-sccp.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-iosfw.shtml * http://www.cisco.com/warp/public/707/cisco-sa-20080924-l2tp.shtml Affected Products ================= Products running Cisco IOS versions 12.0S, 12.2, 12.3 or 12.4 and configured for MPLS VPNs or VRF Lite are potentially affected. Cisco IOS releases based on 12.1 are not affected. Vulnerable Products +------------------ Cisco IOS devices are vulnerable if they are configured for MPLS VPN or VRF Lite and have a BGP session between the CE and PE devices, and process extended communities. If a device is configured for MPLS VPN or VRF Lite the command address-family ipv4 vrf or address-family ipv6 vrf will be present in the device configuration. The following shows a command executed on a device configured for MPLS VPN: router#show running-config | include address-family [ipv4|ipv6] address-family ipv4 vrf The following shows a PE device configured for an IPv4 BGP session between the PE and the CE: router bgp address-family ipv4 vrf one neighbor remote-as < Remote AS> neighbor activate To determine the software running on a Cisco product, log in to the device and issue the "show version" command to display the system banner. Cisco IOS software will identify itself as "Internetwork Operating System Software" or simply "IOS". On the next line of output, the image name will be displayed between parentheses, followed by "Version" and the IOS release name. Other Cisco devices will not have the "show version" command or will give different output. The following example identifies a Cisco product that is running Cisco IOS release 12.4(11)T2: Router#show version Cisco IOS Software, 7200 Software (C7200-ADVSECURITYK9-M), Version 12.4(11)T2, RELEASE SOFTWARE (fc4) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2007 by Cisco Systems, Inc. Compiled Tue 01-May-07 04:19 by prod_rel_team Additional information on the Cisco IOS release naming conventions can be found on the document entitled "White Paper: Cisco IOS Reference Guide", which is available at http://www.cisco.com/warp/public/620/1.html Products Confirmed Not Vulnerable +-------------------------------- Cisco products not configured for MPLS VPNs or VRF Lite are unaffected by this vulnerability. Cisco products that do not run IOS are unaffected by this vulnerability. Cisco IOS-XR is not affected. No other Cisco products are currently known to be affected by this vulnerability. Details ======= MPLS VPNs allow for the creation of 'virtual networks' that customers can use to segregate traffic into multiple, isolated VPNs. Traffic within each MPLS VPN is kept separate from the others, thereby maintaining a virtual private network. More information on MPLS and MPLS VPNs is available at the following link: http://www.cisco.com/en/US/products/ps6557/products_ios_technology_home.html A bug exists when processing extended communities with MPLS VPNs. If extended communities are used, MPLS VPN may incorrectly use a corrupted route target (RT) to forward traffic. If this occurs, traffic can leak from one MPLS VPN to another. This vulnerability exists whenever an affected PE device has a BGP session running in the MPLS VPN Virtual Routing and Forwarding (VRF). The following two examples of this scenario are the most common: 1) MPLS VPN configuration with BGP running inside the VRF between the PE and CE devices. 2) MPLS Inter-AS option A with BGP running between the Autonomous System Border Routers (ASBR). The mitigation in the Workarounds section filters extended communities on a PE device, preventing them from being received by devices configured for MPLS VPN. This vulnerability was introduced with Cisco bug ID CSCee83237. Cisco IOS images that do not include CSCee83237 are not vulnerable to this issue. It is important to note that this condition cannot be triggered by an attacker and that the condition does not provide ways to determine the flow of traffic between VPNs. This vulnerability is documented in the Cisco Bug ID CSCec12299 and has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2008-3803. 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 CVSS Base Score - 5.1 Access Vector - Network Access Complexity - High Authentication - None Confidentiality Impact - Partial Integrity Impact - Partial Availability Impact - Partial CVSS Temporal Score - 4.2 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== This vulnerability may cause traffic to be improperly routed between MPLS VPNs, which may lead to a breach of confidentiality. 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. Each row of the Cisco IOS software table (below) names a Cisco IOS 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 Repaired Releases | | Release | | |--------------+----------------------------------------------------| | Affected | | Recommended | | 12.0-Based | First Fixed Release | Release | | Releases | | | |--------------+----------------------------------+-----------------| | 12.0 | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0DA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0DB | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0DC | Not Vulnerable | | |--------------+----------------------------------+-----------------| | | 12.0(30)S5 | | | | | 12.0(32)S11 | | 12.0S | 12.0(31)S3 | | | | | 12.0(33)S1 | | | 12.0(32)S | | |--------------+----------------------------------+-----------------| | 12.0SC | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0SL | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0SP | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0ST | Not Vulnerable | | |--------------+----------------------------------+-----------------| | | | 12.0(32)S11 | | 12.0SX | Vulnerable; first fixed in 12.0S | | | | | 12.0(33)S1 | |--------------+----------------------------------+-----------------| | 12.0SY | Not Vulnerable | | |--------------+----------------------------------+-----------------| | | | 12.0(32)S11 | | 12.0SZ | 12.0(30)SZ4 | | | | | 12.0(33)S1 | |--------------+----------------------------------+-----------------| | 12.0T | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0W | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0WC | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0WT | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XB | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XC | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XD | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XE | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XF | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XG | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XH | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XI | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XJ | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XK | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XL | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XM | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XN | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XQ | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XR | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XS | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XT | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.0XV | Not Vulnerable | | |--------------+----------------------------------+-----------------| | Affected | | Recommended | | 12.1-Based | First Fixed Release | Release | | Releases | | | |-------------------------------------------------------------------| | There are no affected 12.1 based releases | |-------------------------------------------------------------------| | Affected | | Recommended | | 12.2-Based | First Fixed Release | Release | | Releases | | | |--------------+----------------------------------+-----------------| | 12.2 | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2B | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2BC | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2BW | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2BX | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2BY | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2BZ | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2CX | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2CY | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2CZ | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2DA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2DD | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2DX | 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.2IRB | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2IXA | Vulnerable; migrate to any | 12.2(18)IXG | | | release in 12.2IXD | | |--------------+----------------------------------+-----------------| | 12.2IXB | Vulnerable; migrate to any | 12.2(18)IXG | | | release in 12.2IXD | | |--------------+----------------------------------+-----------------| | 12.2IXC | Vulnerable; migrate to any | 12.2(18)IXG | | | release in 12.2IXD | | |--------------+----------------------------------+-----------------| | 12.2IXD | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2IXE | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2IXF | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2IXG | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2JA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2JK | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2MB | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2MC | Not Vulnerable | | |--------------+----------------------------------+-----------------| | | 12.2(30)S and later are | 12.2(33)SB2; | | 12.2S | vulnerable. 12.2(25)S and before | Available on | | | are not vulnerable | 26-SEP-08 | |--------------+----------------------------------+-----------------| | | 12.2(28)SB5 | | | | | 12.2(33)SB2; | | 12.2SB | 12.2(31)SB2 | Available on | | | | 26-SEP-08 | | | 12.2(31)SB3x | | |--------------+----------------------------------+-----------------| | | Vulnerable; first fixed in | 12.2(33)SB2; | | 12.2SBC | 12.2SB | Available on | | | | 26-SEP-08 | |--------------+----------------------------------+-----------------| | 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 | 12.2(37)SG | 12.2(46)SG1 | |--------------+----------------------------------+-----------------| | 12.2SGA | 12.2(31)SGA8 | 12.2(31)SGA8 | |--------------+----------------------------------+-----------------| | 12.2SL | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2SM | 12.2(29)SM2 | 12.2(29)SM4 | |--------------+----------------------------------+-----------------| | 12.2SO | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2SRA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2SRB | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2SRC | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2SU | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2SV | 12.2(29b)SV1 | | |--------------+----------------------------------+-----------------| | 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 | Vulnerable; first fixed in | 12.2(18)SXF15 | | | 12.2SXF | | |--------------+----------------------------------+-----------------| | 12.2SXF | 12.2(18)SXF3 | 12.2(18)SXF15 | |--------------+----------------------------------+-----------------| | 12.2SXH | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2SY | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2SZ | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2T | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2TPC | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XB | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XC | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XD | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XE | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XF | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XG | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XH | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XI | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XJ | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XK | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XL | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XM | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XN | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XNA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XNB | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XO | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XQ | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XR | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XS | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XT | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2XU | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 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 | | |--------------+----------------------------------+-----------------| | 12.2YJ | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YK | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YL | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YM | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YN | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YO | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YP | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YQ | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YR | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YS | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YT | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YU | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YV | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YW | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YX | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YY | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2YZ | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2ZA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2ZB | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2ZC | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2ZD | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2ZE | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2ZF | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2ZG | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2ZH | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2ZJ | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2ZL | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2ZP | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2ZU | Not Vulnerable | | |--------------+----------------------------------+-----------------| | | Vulnerable; first fixed in | 12.2(33)SB2; | | 12.2ZX | 12.2SB | Available on | | | | 26-SEP-08 | |--------------+----------------------------------+-----------------| | 12.2ZY | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.2ZYA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | Affected | | Recommended | | 12.3-Based | First Fixed Release | Release | | Releases | | | |--------------+----------------------------------+-----------------| | 12.3 | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3B | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3BC | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3BW | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 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 | | |--------------+----------------------------------+-----------------| | | | 12.4(15)T7 | | 12.3T | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |--------------+----------------------------------+-----------------| | 12.3TPC | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3VA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3XA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3XB | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3XC | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3XD | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3XE | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3XF | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3XG | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3XI | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3XJ | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3XK | Not Vulnerable | | |--------------+----------------------------------+-----------------| | | | 12.4(15)T7 | | 12.3XL | Vulnerable; first fixed in 12.4 | | | | | 12.4(18c) | |--------------+----------------------------------+-----------------| | 12.3XQ | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3XR | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3XS | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3XU | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3XW | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3XX | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3XY | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3XZ | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3YA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3YD | Not Vulnerable | | |--------------+----------------------------------+-----------------| | | Vulnerable; first fixed in | 12.3(14)YX13 | | 12.3YF | 12.3YX | | | | | 12.4(15)T7 | |--------------+----------------------------------+-----------------| | 12.3YG | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3YH | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3YI | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.3YJ | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |--------------+----------------------------------+-----------------| | 12.3YK | 12.3(11)YK3 | 12.4(15)T7 | |--------------+----------------------------------+-----------------| | | | 12.3(14)YM13; | | 12.3YM | 12.3(14)YM10 | Available on | | | | 30-SEP-08 | |--------------+----------------------------------+-----------------| | 12.3YQ | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |--------------+----------------------------------+-----------------| | 12.3YS | 12.3(11)YS2 | 12.4(15)T7 | |--------------+----------------------------------+-----------------| | 12.3YT | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |--------------+----------------------------------+-----------------| | | | 12.4(2)XB10 | | | Vulnerable; first fixed in | | | 12.3YU | 12.4XB | 12.4(9)XG3 | | | | | | | | 12.4(15)T7 | |--------------+----------------------------------+-----------------| | 12.3YX | 12.3(14)YX7 | 12.3(14)YX13 | |--------------+----------------------------------+-----------------| | 12.3YZ | 12.3(11)YZ2 | | |--------------+----------------------------------+-----------------| | 12.3ZA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | Affected | | Recommended | | 12.4-Based | First Fixed Release | Release | | Releases | | | |--------------+----------------------------------+-----------------| | | 12.4(10c) | | | | | | | | 12.4(12a) | | | | | | | | 12.4(13) | | | | | | | 12.4 | 12.4(3h) | 12.4(18c) | | | | | | | 12.4(5c) | | | | | | | | 12.4(7e) | | | | | | | | 12.4(8d) | | |--------------+----------------------------------+-----------------| | 12.4JA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.4JK | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.4JL | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.4JMA | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.4JMB | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.4JMC | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.4JX | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.4MD | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.4MR | Not Vulnerable | | |--------------+----------------------------------+-----------------| | | | 12.4(15)SW2; | | 12.4SW | 12.4(11)SW1 | Available on | | | | 28-SEP-08 | |--------------+----------------------------------+-----------------| | | 12.4(11)T2 | | | | | | | | 12.4(15)T | | | | | | | | 12.4(2)T6 | | | 12.4T | | 12.4(15)T7 | | | 12.4(4)T8 | | | | | | | | 12.4(6)T7 | | | | | | | | 12.4(9)T3 | | |--------------+----------------------------------+-----------------| | 12.4XA | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |--------------+----------------------------------+-----------------| | 12.4XB | 12.4(2)XB6 | 12.4(2)XB10 | |--------------+----------------------------------+-----------------| | 12.4XC | 12.4(4)XC7 | 12.4(15)T7 | |--------------+----------------------------------+-----------------| | | | 12.4(4)XD11; | | 12.4XD | 12.4(4)XD7 | Available on | | | | 26-SEP-08 | |--------------+----------------------------------+-----------------| | 12.4XE | 12.4(6)XE3 | 12.4(15)T7 | |--------------+----------------------------------+-----------------| | 12.4XF | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.4XG | 12.4(9)XG2 | 12.4(9)XG3 | |--------------+----------------------------------+-----------------| | 12.4XJ | 12.4(11)XJ2 | 12.4(15)T7 | |--------------+----------------------------------+-----------------| | 12.4XK | Vulnerable; first fixed in 12.4T | 12.4(15)T7 | |--------------+----------------------------------+-----------------| | 12.4XL | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.4XM | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.4XN | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.4XP | Vulnerable; contact TAC | | |--------------+----------------------------------+-----------------| | 12.4XQ | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.4XR | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.4XT | 12.4(6)XT1 | 12.4(15)T7 | |--------------+----------------------------------+-----------------| | 12.4XV | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.4XW | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.4XY | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.4XZ | Not Vulnerable | | |--------------+----------------------------------+-----------------| | 12.4YA | Not Vulnerable | | +-------------------------------------------------------------------+ Workarounds =========== Customers running versions of Cisco IOS that support filtering of extended communities can prevent the corruption of the route target (RT) by applying a BGP route-map that removes RT entries on inbound BGP sessions. The following configuration example applied in the ipv4 address family of a PE device removes extended communities from the CE router: router bgp address-family ipv4 vrf one neighbor remote-as neighbor activate neighbor route-map FILTER in exit-address-family ! ip extcommunity-list 100 permit _RT.*_ ! ! route-map FILTER permit 10 set extcomm-list 100 delete ! The following configuration example applied in the ipv6 address family of a PE device removes extended communities from the CE router: router bgp address-family ipv6 vrf one neighbor remote-as neighbor activate neighbor route-map FILTER in exit-address-family ! ip extcommunity-list 100 permit _RT.*_ ! ! route-map FILTER permit 10 set extcomm-list 100 delete ! Note: The capability of filtering extended communities is only available in certain 12.0S and 12.2S based Cisco IOS releases. BGP session between the PE and the CE needs to cleared to make this configuration change effective. 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. This vulnerability was reported to Cisco by a customer. This vulnerability cannot be deterministically triggered by an attacker. 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-20080924-vpn.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-bulletins at lists.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 | | Initial | | 1.0 | 2008-Sep-24 | 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjaLeoACgkQ86n/Gc8U/uCNwQCdEOd3v5A+paECb9s2gMBUr0JH DEwAnRtvu3aQrECRin/QmElp7oudHZJX =EVLU -----END PGP SIGNATURE----- From pauldotwall at gmail.com Wed Sep 24 13:25:25 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Wed, 24 Sep 2008 14:25:25 -0400 Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <548200.23333.qm@web45014.mail.sp1.yahoo.com> References: <548200.23333.qm@web45014.mail.sp1.yahoo.com> Message-ID: <620fd17c0809241125y32f320b1h4ad1bf09b0393826@mail.gmail.com> On Wed, Sep 24, 2008 at 12:13 AM, Russell Mitchell wrote: > Hello Paul, > > Those are their IP Blocks. We were simply routing them, as they were our client. > They've owned these blocks for quite a while. They seem to have moved that after a day of being down. You're not very good at this are you? For future reference, when you're trying to pretend like you've cleaned up your act and someone asks you why your second largest cyber criminal customer is no longer on your network, you say "we kicked them off for abuse too", not "they left us after a day of being down due to outages caused by our hosting of an even bigger criminal". Drive Slow, Paul Wall From LarrySheldon at cox.net Wed Sep 24 13:30:59 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Wed, 24 Sep 2008 13:30:59 -0500 Subject: YAY! Re: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <620fd17c0809241125y32f320b1h4ad1bf09b0393826@mail.gmail.com> References: <548200.23333.qm@web45014.mail.sp1.yahoo.com> <620fd17c0809241125y32f320b1h4ad1bf09b0393826@mail.gmail.com> Message-ID: <48DA8763.1010902@cox.net> Paul Wall wrote: > You're not very good at this are you? For future reference, when > you're trying to pretend like you've cleaned up your act and someone > asks you why your second largest cyber criminal customer is no longer > on your network, you say "we kicked them off for abuse too", not "they > left us after a day of being down due to outages caused by our hosting > of an even bigger criminal". Or demonstrate that, unlike the left side of our political spectrum, you can learn the instruction of the Law of Holes. You _can_ do that, right? Right?? Oh. I see. You are on the freelunch side too, aren't you? From ml at t-b-o-h.net Wed Sep 24 13:44:05 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Wed, 24 Sep 2008 14:44:05 -0400 (EDT) Subject: Silly PUCK/Outages question Message-ID: <200809241844.m8OIi5Nk014195@himinbjorg.tucs-beachin-obx-house.com> Hi, I hate to use NANOG for outages... But can anyone else get to puck.nether.net or the outages.org list? A traceroute gets me into Chicago with NTT and then dies...(Along with high ping times between NY and IL for NTT) I'm looking to see if anyone has more info about an S&D power event at 111 8th this morning. (And I contacted S&D and am getting nothing from them). Thanks, Tuc/TBOH From LarrySheldon at cox.net Wed Sep 24 13:48:48 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Wed, 24 Sep 2008 13:48:48 -0500 Subject: Silly PUCK/Outages question In-Reply-To: <200809241844.m8OIi5Nk014195@himinbjorg.tucs-beachin-obx-house.com> References: <200809241844.m8OIi5Nk014195@himinbjorg.tucs-beachin-obx-house.com> Message-ID: <48DA8B90.8080904@cox.net> Tuc, stuck on puck wrote: > I hate to use NANOG for outages... But can anyone else get to > puck.nether.net or the outages.org list? outages.org doesn't even resolve here (cox in Omaha). From woody at pch.net Wed Sep 24 13:51:22 2008 From: woody at pch.net (Bill Woodcock) Date: Wed, 24 Sep 2008 11:51:22 -0700 (PDT) Subject: Silly PUCK/Outages question In-Reply-To: <200809241844.m8OIi5Nk014195@himinbjorg.tucs-beachin-obx-house.com> References: <200809241844.m8OIi5Nk014195@himinbjorg.tucs-beachin-obx-house.com> Message-ID: On Wed, 24 Sep 2008, Tuc at T-B-O-H.NET wrote: > I hate to use NANOG for outages... But can anyone else get to > puck.nether.net or the outages.org list? As regards Puck, so says Jared: > INCORRECT BLOCK COUNT I=121740614 (24704 should be 24736) > CORRECT? yes > ** Phase 2 - Check Pathnames -Bill From brandon.galbraith at gmail.com Wed Sep 24 13:53:01 2008 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Wed, 24 Sep 2008 13:53:01 -0500 Subject: Silly PUCK/Outages question In-Reply-To: <48DA8B90.8080904@cox.net> References: <200809241844.m8OIi5Nk014195@himinbjorg.tucs-beachin-obx-house.com> <48DA8B90.8080904@cox.net> Message-ID: <366100670809241153q690687fas3c4817f6561dfd4c@mail.gmail.com> Not resolving on Comcast in Chicago either. -brandon On 9/24/08, Laurence F. Sheldon, Jr. wrote: > > Tuc, stuck on puck wrote: > > > I hate to use NANOG for outages... But can anyone else get to >> puck.nether.net or the outages.org list? >> > > outages.org doesn't even resolve here (cox in Omaha). > > From morrowc.lists at gmail.com Wed Sep 24 13:55:13 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 24 Sep 2008 14:55:13 -0400 Subject: Silly PUCK/Outages question In-Reply-To: <48DA8B90.8080904@cox.net> References: <200809241844.m8OIi5Nk014195@himinbjorg.tucs-beachin-obx-house.com> <48DA8B90.8080904@cox.net> Message-ID: <75cb24520809241155l59b0532cu685cc0e306e27b1d@mail.gmail.com> On Wed, Sep 24, 2008 at 2:48 PM, Laurence F. Sheldon, Jr. wrote: > Tuc, stuck on puck wrote: > > >> I hate to use NANOG for outages... But can anyone else get to >> puck.nether.net or the outages.org list? > > outages.org doesn't even resolve here (cox in Omaha). $ dig NS outages.org @tld2.ultradns.net ;; QUESTION SECTION: ;outages.org. IN NS ;; AUTHORITY SECTION: outages.org. 86400 IN NS puck.nether.net. outages.org. 86400 IN NS anyns.pch.net. $ dig NS outages.org @204.61.216.4 ;; QUESTION SECTION: ;outages.org. IN NS ;; AUTHORITY SECTION: org. 172800 IN NS D0.ORG.AFILIAS-NST.org. org. 172800 IN NS TLD1.ULTRADNS.NET. org. 172800 IN NS C0.ORG.AFILIAS-NST.INFO. org. 172800 IN NS TLD2.ULTRADNS.NET. org. 172800 IN NS B0.ORG.AFILIAS-NST.org. org. 172800 IN NS A0.ORG.AFILIAS-NST.INFO. incorrect NS record setup maybe?? -chris From brandon.galbraith at gmail.com Wed Sep 24 13:59:16 2008 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Wed, 24 Sep 2008 13:59:16 -0500 Subject: Reporting abuse to ISP that goes nowhere Message-ID: <366100670809241159w3ef925e7j9f71a32c28e600cf@mail.gmail.com> Apologies for the operational content. =) I've been working with a client who has been the victim of several SQL injection attacks. These attacks are being used to insert links to malicious javascript hosted elsewhere using the following domains: seekcc.com google9.info any-park.cn I've reported the abuse several times to the abuse contact listed by ARIN, but it seems to simply be a blackhole at Verizon Business (their address space). How have others handled this problem? Also, if there is a more appropriate forum for this question and forthcoming discussion, please let me know. Thanks! -brandon From braaen at zcorum.com Wed Sep 24 13:59:31 2008 From: braaen at zcorum.com (Brian Raaen) Date: Wed, 24 Sep 2008 14:59:31 -0400 Subject: Silly PUCK/Outages question In-Reply-To: <200809241844.m8OIi5Nk014195@himinbjorg.tucs-beachin-obx-house.com> References: <200809241844.m8OIi5Nk014195@himinbjorg.tucs-beachin-obx-house.com> Message-ID: <200809241459.33455.braaen@zcorum.com> As I'm unable to resolve the DNS name, I can't reach them either. Their secondary server in the whois is not giving correct info either braaen at brian-debian:~$ dig @204.42.254.5 PUCK.NETHER.NET ; <<>> DiG 9.5.0-P2 <<>> @204.42.254.5 PUCK.NETHER.NET ; (1 server found) ;; global options: printcmd ;; connection timed out; no servers could be reached braaen at brian-debian:~$ braaen at brian-debian:~$ braaen at brian-debian:~$ braaen at brian-debian:~$ braaen at brian-debian:~$ braaen at brian-debian:~$ braaen at brian-debian:~$ braaen at brian-debian:~$ dig @204.61.216.4 PUCK.NETHER.NET ; <<>> DiG 9.5.0-P2 <<>> @204.61.216.4 PUCK.NETHER.NET ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58498 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 14 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;PUCK.NETHER.NET. IN A ;; AUTHORITY SECTION: NET. 172800 IN NS M.GTLD-SERVERS.NET. NET. 172800 IN NS A.GTLD-SERVERS.NET. NET. 172800 IN NS G.GTLD-SERVERS.NET. NET. 172800 IN NS I.GTLD-SERVERS.NET. NET. 172800 IN NS L.GTLD-SERVERS.NET. NET. 172800 IN NS B.GTLD-SERVERS.NET. NET. 172800 IN NS C.GTLD-SERVERS.NET. NET. 172800 IN NS H.GTLD-SERVERS.NET. NET. 172800 IN NS K.GTLD-SERVERS.NET. NET. 172800 IN NS E.GTLD-SERVERS.NET. NET. 172800 IN NS F.GTLD-SERVERS.NET. NET. 172800 IN NS J.GTLD-SERVERS.NET. NET. 172800 IN NS D.GTLD-SERVERS.NET. ;; ADDITIONAL SECTION: A.GTLD-SERVERS.NET. 172800 IN A 192.5.6.30 A.GTLD-SERVERS.NET. 172800 IN AAAA 2001:503:a83e::2:30 B.GTLD-SERVERS.NET. 172800 IN A 192.33.14.30 B.GTLD-SERVERS.NET. 172800 IN AAAA 2001:503:231d::2:30 C.GTLD-SERVERS.NET. 172800 IN A 192.26.92.30 D.GTLD-SERVERS.NET. 172800 IN A 192.31.80.30 E.GTLD-SERVERS.NET. 172800 IN A 192.12.94.30 F.GTLD-SERVERS.NET. 172800 IN A 192.35.51.30 G.GTLD-SERVERS.NET. 172800 IN A 192.42.93.30 H.GTLD-SERVERS.NET. 172800 IN A 192.54.112.30 I.GTLD-SERVERS.NET. 172800 IN A 192.43.172.30 J.GTLD-SERVERS.NET. 172800 IN A 192.48.79.30 K.GTLD-SERVERS.NET. 172800 IN A 192.52.178.30 L.GTLD-SERVERS.NET. 172800 IN A 192.41.162.30 ;; Query time: 65 msec ;; SERVER: 204.61.216.4#53(204.61.216.4) ;; WHEN: Wed Sep 24 14:58:24 2008 ;; MSG SIZE rcvd: 502 ---------------------- Brian Raaen Network Engineer braaen at zcorum.com Tel 678-507-5000x5574 On Wednesday 24 September 2008, Tuc at T-B-O-H.NET wrote: > Hi, > > I hate to use NANOG for outages... But can anyone else get to > puck.nether.net or the outages.org list? A traceroute gets me into > Chicago with NTT and then dies...(Along with high ping times between > NY and IL for NTT) > > I'm looking to see if anyone has more info about an S&D power > event at 111 8th this morning. (And I contacted S&D and am getting > nothing from them). > > Thanks, Tuc/TBOH > > From rjoffe at centergate.com Wed Sep 24 14:04:08 2008 From: rjoffe at centergate.com (Rodney Joffe) Date: Wed, 24 Sep 2008 12:04:08 -0700 Subject: Silly PUCK/Outages question In-Reply-To: <75cb24520809241155l59b0532cu685cc0e306e27b1d@mail.gmail.com> References: <200809241844.m8OIi5Nk014195@himinbjorg.tucs-beachin-obx-house.com> <48DA8B90.8080904@cox.net> <75cb24520809241155l59b0532cu685cc0e306e27b1d@mail.gmail.com> Message-ID: Perhaps you should report it to outages? ;-) On Sep 24, 2008, at 11:55 AM, Christopher Morrow wrote: > On Wed, Sep 24, 2008 at 2:48 PM, Laurence F. Sheldon, Jr. > wrote: >> Tuc, stuck on puck wrote: >> >> >>> I hate to use NANOG for outages... But can anyone else get to >>> puck.nether.net or the outages.org list? >> >> outages.org doesn't even resolve here (cox in Omaha). > $ dig NS outages.org @tld2.ultradns.net > ;; QUESTION SECTION: > ;outages.org. IN NS > > ;; AUTHORITY SECTION: > outages.org. 86400 IN NS puck.nether.net. > outages.org. 86400 IN NS anyns.pch.net. > > $ dig NS outages.org @204.61.216.4 > ;; QUESTION SECTION: > ;outages.org. IN NS > > ;; AUTHORITY SECTION: > org. 172800 IN NS D0.ORG.AFILIAS-NST.org. > org. 172800 IN NS TLD1.ULTRADNS.NET. > org. 172800 IN NS C0.ORG.AFILIAS-NST.INFO. > org. 172800 IN NS TLD2.ULTRADNS.NET. > org. 172800 IN NS B0.ORG.AFILIAS-NST.org. > org. 172800 IN NS A0.ORG.AFILIAS-NST.INFO. > > > incorrect NS record setup maybe?? > > -chris > From woody at pch.net Wed Sep 24 14:02:52 2008 From: woody at pch.net (Bill Woodcock) Date: Wed, 24 Sep 2008 12:02:52 -0700 (PDT) Subject: Silly PUCK/Outages question In-Reply-To: <75cb24520809241155l59b0532cu685cc0e306e27b1d@mail.gmail.com> References: <200809241844.m8OIi5Nk014195@himinbjorg.tucs-beachin-obx-house.com> <48DA8B90.8080904@cox.net> <75cb24520809241155l59b0532cu685cc0e306e27b1d@mail.gmail.com> Message-ID: On Wed, 24 Sep 2008, Christopher Morrow wrote: > ;; AUTHORITY SECTION: > outages.org. 86400 IN NS puck.nether.net. > outages.org. 86400 IN NS anyns.pch.net. > > incorrect NS record setup maybe?? That too. We're moving the records we have over to anyns, which should pick them up within the hour. -Bill From smb at cs.columbia.edu Wed Sep 24 14:08:20 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Wed, 24 Sep 2008 15:08:20 -0400 Subject: Silly PUCK/Outages question In-Reply-To: <200809241459.33455.braaen@zcorum.com> References: <200809241844.m8OIi5Nk014195@himinbjorg.tucs-beachin-obx-house.com> <200809241459.33455.braaen@zcorum.com> Message-ID: <20080924150820.198333b1@cs.columbia.edu> http://downforeveryoneorjustme.com can't resolve it, either. From ml at t-b-o-h.net Wed Sep 24 14:15:18 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Wed, 24 Sep 2008 15:15:18 -0400 (EDT) Subject: Silly PUCK/Outages question In-Reply-To: <20080924150820.198333b1@cs.columbia.edu> Message-ID: <200809241915.m8OJFIHk014594@himinbjorg.tucs-beachin-obx-house.com> > > http://downforeveryoneorjustme.com can't resolve it, either. > Sorry, I should have mentioned that. Tuc/TBOH From jscott at gravityfree.com Wed Sep 24 14:19:27 2008 From: jscott at gravityfree.com (Justin Scott) Date: Wed, 24 Sep 2008 15:19:27 -0400 Subject: Silly PUCK/Outages question In-Reply-To: <20080924150820.198333b1@cs.columbia.edu> References: <200809241844.m8OIi5Nk014195@himinbjorg.tucs-beachin-obx-house.com> <200809241459.33455.braaen@zcorum.com> <20080924150820.198333b1@cs.columbia.edu> Message-ID: <48DA92BF.5080205@gravityfree.com> Steven M. Bellovin wrote: > http://downforeveryoneorjustme.com can't resolve it, either. That one appears to have one DNS server that is up and down, but the other two are up and I'm able to resolve and access it from here (Comcast Business connection in Florida). For outages.org, it appears that one of the two DNS servers is reporting a lame delegation (204.61.216.4), and the other isn't responding at all (204.42.254.5). The two sites are not using the same DNS servers, so likely unrelated issues. -Justin Scott -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3257 bytes Desc: S/MIME Cryptographic Signature URL: From jared at puck.nether.net Wed Sep 24 14:45:27 2008 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 24 Sep 2008 15:45:27 -0400 Subject: Silly PUCK/Outages question In-Reply-To: <200809241915.m8OJFIHk014594@himinbjorg.tucs-beachin-obx-house.com> References: <20080924150820.198333b1@cs.columbia.edu> <200809241915.m8OJFIHk014594@himinbjorg.tucs-beachin-obx-house.com> Message-ID: <20080924194527.GA6091@puck.nether.net> On Wed, Sep 24, 2008 at 03:15:18PM -0400, Tuc at T-B-O-H.NET wrote: > > > > http://downforeveryoneorjustme.com can't resolve it, either. > > > Sorry, I should have mentioned that. Seems to work for me now. Those that care: 1) the outages.org ns issue should hopefully be resolved 2) i've had a phantom issue that cropped up today and caused me to toy with the system some. hopefully i won't have a need to touch it again today and it can run for another 160+ days without issues. 3) sorry that this happened on a day where all the PSIRT stuff went out. I really do try to keep the host up 100% of the time, but as most people here know, there are limits to that in reality. I now return you to your regularly secheduled depeering/abuse discussion. - 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 heather.schiller at verizonbusiness.com Wed Sep 24 15:39:22 2008 From: heather.schiller at verizonbusiness.com (Heather Schiller) Date: Wed, 24 Sep 2008 16:39:22 -0400 Subject: Reporting abuse to ISP that goes nowhere In-Reply-To: <366100670809241159w3ef925e7j9f71a32c28e600cf@mail.gmail.com> References: <366100670809241159w3ef925e7j9f71a32c28e600cf@mail.gmail.com> Message-ID: <48DAA57A.8010406@verizonbusiness.com> If you forward me your ticket numbers privately, I'll take a look. Despite popular belief, we actually have an active abuse team of good folks who care about abuse issues! --Heather ~*~*~*~*~*~*~*~*~*~*~*~ Heather Schiller Customer Security IP Address Management 1.800.900.0241 ~*~*~*~*~*~*~*~*~*~*~*~ Brandon Galbraith wrote: > Apologies for the operational content. =) > > I've been working with a client who has been the victim of several SQL > injection attacks. These attacks are being used to insert links to malicious > javascript hosted elsewhere using the following domains: > > seekcc.com > google9.info > any-park.cn > > I've reported the abuse several times to the abuse contact listed by ARIN, > but it seems to simply be a blackhole at Verizon Business (their address > space). How have others handled this problem? Also, if there is a more > appropriate forum for this question and forthcoming discussion, please let > me know. > > Thanks! > -brandon > From info at spokompton.net Wed Sep 24 18:40:41 2008 From: info at spokompton.net (A MacLeod) Date: Wed, 24 Sep 2008 16:40:41 -0700 Subject: AOL NOC Contact Information Message-ID: Could someone please send me AOL's NOC contact information off list? From nenolod at systeminplace.net Wed Sep 24 19:12:31 2008 From: nenolod at systeminplace.net (William Pitcock) Date: Wed, 24 Sep 2008 19:12:31 -0500 Subject: Atrivo/Intercage In-Reply-To: <20080924070641.8B7EEC6D@resin17.mta.everyone.net> References: <20080924070641.8B7EEC6D@resin17.mta.everyone.net> Message-ID: <1222301551.20200.1342.camel@petrie.sacredspiral.co.uk> Hi, On Wed, 2008-09-24 at 07:06 -0700, Scott Weeks wrote: > --- trelane at trelane.net wrote: > From: Andrew D Kirch > > > Basically is what it boils down to for me - its > > easy to blame an NSP/ISP/Hoster for what their > > clients do, it takes real dedication to find out > > whats *actually* going on. > > : We did, and now we're solving the problem. > ------------------------------------------ > > > > Apparently, this is what's going on. Making money at the expense of everyone else on the internet: > > --------------------------- > > If I had the ability... I would cut Esthost as a > > client... But, in doing so, it causes nearly a > > quarter if not half of the company's monthly > > revenue to be cut. That is not too good of a move > > nor reasonably possible ;) > > > > People consider Atrivo/InterCage to be some abuse > > supporting company... > > > > If only any of you knew what the position would be > > in a company our size. > > > > It's not as easy as you believe it to be ;) > > > > Russell Mitchell - Russ[at]Atrivo.com > > Atrivo Technologies > ------------------------------ > > ?Esthost (the main problem) is actually cut off as of this morning. So actually, they are taking steps to fix the problem. However, as we all know, there is the real story, and then there is the NANOG story. We should keep this all in mind, Intercage are actually trying hard to clean up their network, and now is the time to stop with the whining and actually help them identify the problems. Esthost is a tricky situation because it is a significant portion of their income... but they are offline. I would be reluctant to cut them off too if I were in their position... not because it's the right thing to do, but because they are such a large client that I might not be able to pay the bills at the end of the month. If you were in their position, wouldn't you have concerns about terminating ANY source of income that is that large too? That said, they should have dropped Esthost before it got that big, but they didn't. People make bad choices, but for fucks sake, lets move on already. I have also noticed that most of the people doing the whining aren't even the people who are tracking the problem. Again, a case of the NANOG story verses the real story... William From nanog-post at rsuc.gweep.net Wed Sep 24 19:41:05 2008 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Wed, 24 Sep 2008 20:41:05 -0400 Subject: the Intercage mess In-Reply-To: <20080924133743.944847809@relayer.avian.org> References: <20080924133743.944847809@relayer.avian.org> Message-ID: <20080925004104.GA97924@gweep.net> On Wed, Sep 24, 2008 at 01:37:43PM +0000, *Hobbit* wrote: [snip] > If this happened to some of the other major sources of crap that > I'm thinking of, it would make the freaking NATIONAL NEWS. Where's > the BACKBONE to go after the real high-volume sources, rather than > continuing to kick sand in the face of some podunk little guy who > can no longer defend himself? The spine to do it left with suits minding the store & managing to the tune of fickle investors. For the same reason just refusing deaggregates has become difficult: the bad guys shield themselves by sitting in the same prefix/ASNs with sites your paying customers wish to reach. The suits are interested in - avoiding PR hassles - low call rates into the support centers - lower customer-churn numbers for their investor calls Therefore anyone with time & energy to block badness where there is collateral damage rarely has the stamina or internal political capital to have the suits' spin machine on their side. More network companies that are privately held with actual technocrats at the helm might help bring a vision beyond commoditization and marketing. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From fergdawgster at gmail.com Wed Sep 24 19:53:00 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 24 Sep 2008 17:53:00 -0700 Subject: Renesys Blog Article [Was: Re: the Intercage mess] Message-ID: <6cd462c00809241753l1cb3d5ffk95fcbf5c467a883a@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Sep 24, 2008 at 5:41 PM, Joe Provo wrote: > > The spine to do it left with suits minding the store & managing to > the tune of fickle investors. For the same reason just refusing > deaggregates has become difficult: the bad guys shield themselves > by sitting in the same prefix/ASNs with sites your paying customers > wish to reach. The suits are interested in > - avoiding PR hassles > - low call rates into the support centers > - lower customer-churn numbers for their investor calls > > Therefore anyone with time & energy to block badness where there > is collateral damage rarely has the stamina or internal political > capital to have the suits' spin machine on their side. More > network companies that are privately held with actual technocrats > at the helm might help bring a vision beyond commoditization and > marketing. > Just a side-note: Rensys has an interesting blog article up today on this Atrivo/Intercage "mess": http://www.renesys.com/blog/2008/09/internet_vigilantism_1.shtml FYI, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI2uDeq1pz9mNUZTMRAjCxAKCFwIw4PahuGBTzbRwumog45mQp2QCg/K5D egFWNn4uBnN3Rfyi5Npjfes= =DvXt -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From ge at linuxbox.org Wed Sep 24 20:02:21 2008 From: ge at linuxbox.org (Gadi Evron) Date: Wed, 24 Sep 2008 20:02:21 -0500 (CDT) Subject: Renesys Blog Article [Was: Re: the Intercage mess] In-Reply-To: <6cd462c00809241753l1cb3d5ffk95fcbf5c467a883a@mail.gmail.com> References: <6cd462c00809241753l1cb3d5ffk95fcbf5c467a883a@mail.gmail.com> Message-ID: On Wed, 24 Sep 2008, Paul Ferguson wrote: > Just a side-note: Rensys has an interesting blog article up today on this > Atrivo/Intercage "mess": > > http://www.renesys.com/blog/2008/09/internet_vigilantism_1.shtml > > FYI, I have but one comment. There is a difference between Vigilantism as it is perceived today and Vigilantism as it is in the dictionary. It means neighborhood watch. When the Police is not around, that is something you need. "It's for the children". All in all, very nice blog post. While I feel I can not yet fully comment on the whole Atrivo / Intercage depeering movement, there is an underlying strategy to consider. I will comment at a later date. Gadi. From nenolod at systeminplace.net Wed Sep 24 20:50:20 2008 From: nenolod at systeminplace.net (William Pitcock) Date: Wed, 24 Sep 2008 20:50:20 -0500 Subject: Atrivo/Intercage In-Reply-To: <20080924175449.7907ED80@resin13.mta.everyone.net> References: <20080924175449.7907ED80@resin13.mta.everyone.net> Message-ID: <1222307420.20200.1353.camel@petrie.sacredspiral.co.uk> Hi, On Wed, 2008-09-24 at 17:54 -0700, Scott Weeks wrote: > > --- nenolod at systeminplace.net wrote: > I have also noticed that most of the people doing the whining aren't > even the people who are tracking the problem. Again, a case of the NANOG > story verses the real story... > -------------------------------------- > > > > I didn't whine. No, but others have, and it isn't helpful towards resolving this problem. Ultimately, neither is forcing them off the internet. Well, in actuality, that resolves part of the problem, but I suspect that a lot of the affected cybercrime has moved to other networks by now... so in reality the real problem isn't solved (except that the problem is mostly being moved away from Intercage). And shutting down ISPs who host these guys will solve nothing either. They will jump providers until the end of time. The solution here is to go after the *people* who make this crap. They *are* breaking the law and we have the proof. William From morrowc.lists at gmail.com Wed Sep 24 20:58:26 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 24 Sep 2008 21:58:26 -0400 Subject: Atrivo/Intercage In-Reply-To: <1222307420.20200.1353.camel@petrie.sacredspiral.co.uk> References: <20080924175449.7907ED80@resin13.mta.everyone.net> <1222307420.20200.1353.camel@petrie.sacredspiral.co.uk> Message-ID: <75cb24520809241858la951898v17ce14558b815731@mail.gmail.com> On Wed, Sep 24, 2008 at 9:50 PM, William Pitcock wrote: > The solution here is to go after the *people* who make this crap. They > *are* breaking the law and we have the proof. agreed... but keep in mind 'breaking the law' is relative... So, CP is illegal in the US, but maybe not where it was made (CP's not the best example of course because it lives in a wierd place in everyone's laws)... how about simple hacking? that's illegal in the US (mostly, depending on what's being done) but not in other places, and perhaps not if committed outside the local jurisdiction(s). -Chris From LarrySheldon at cox.net Wed Sep 24 21:02:15 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Wed, 24 Sep 2008 21:02:15 -0500 Subject: Atrivo/Intercage In-Reply-To: <75cb24520809241858la951898v17ce14558b815731@mail.gmail.com> References: <20080924175449.7907ED80@resin13.mta.everyone.net> <1222307420.20200.1353.camel@petrie.sacredspiral.co.uk> <75cb24520809241858la951898v17ce14558b815731@mail.gmail.com> Message-ID: <48DAF127.2070902@cox.net> Christopher Morrow wrote: > On Wed, Sep 24, 2008 at 9:50 PM, William Pitcock > wrote: > >> The solution here is to go after the *people* who make this crap. They >> *are* breaking the law and we have the proof. > > agreed... but keep in mind 'breaking the law' is relative... So, CP is > illegal in the US, but maybe not where it was made (CP's not the best > example of course because it lives in a wierd place in everyone's > laws)... how about simple hacking? that's illegal in the US (mostly, > depending on what's being done) but not in other places, and perhaps > not if committed outside the local jurisdiction(s). Apprehending criminals is the Law's job. My job is making sure they don't deal that sh*t in MY parkinglot. From ge at linuxbox.org Wed Sep 24 21:05:43 2008 From: ge at linuxbox.org (Gadi Evron) Date: Wed, 24 Sep 2008 21:05:43 -0500 (CDT) Subject: Atrivo/Intercage In-Reply-To: <1222307420.20200.1353.camel@petrie.sacredspiral.co.uk> References: <20080924175449.7907ED80@resin13.mta.everyone.net> <1222307420.20200.1353.camel@petrie.sacredspiral.co.uk> Message-ID: On Wed, 24 Sep 2008, William Pitcock wrote: > No, but others have, and it isn't helpful towards resolving this > problem. > > Ultimately, neither is forcing them off the internet. Well, in > actuality, that resolves part of the problem, but I suspect that a lot > of the affected cybercrime has moved to other networks by now... so in > reality the real problem isn't solved (except that the problem is mostly > being moved away from Intercage). And shutting down ISPs who host these > guys will solve nothing either. They will jump providers until the end > of time. The fear is evolution in technological advancement they may make rather than just where they will scatter to, but that is a solid point. Still, we have seen in the past that they evolve regardless. The future will tell whether this was a foolishness, or a step in the right directions. > The solution here is to go after the *people* who make this crap. They > *are* breaking the law and we have the proof. I couldn't agree more. Unfortunately, that isn't happening. Whethr I like it or not there are two layers of attackers. The initiator, and the proxy. The proxy is on networks, and networks we can reach out to. Gadi. > > William > > From rsk at gsp.org Wed Sep 24 21:07:01 2008 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 24 Sep 2008 22:07:01 -0400 Subject: Atrivo/Intercage In-Reply-To: <1222301551.20200.1342.camel@petrie.sacredspiral.co.uk> References: <20080924070641.8B7EEC6D@resin17.mta.everyone.net> <1222301551.20200.1342.camel@petrie.sacredspiral.co.uk> Message-ID: <20080925020701.GA29247@gsp.org> On Wed, Sep 24, 2008 at 07:12:31PM -0500, William Pitcock wrote: > That said, they should have dropped Esthost before it got that big, but > they didn't. Didn't you notice that the quoted material was from *three years ago*? And this problem didn't begin three years ago, either. For example: > From furioun at spin.it Fri Dec 5 09:53:14 EST 2003 > Article: 1141964 of news.admin.net-abuse.email > From: furio ercolessi > Newsgroups: news.admin.net-abuse.email > Subject: AS27595 (Atrivo) here no more > Date: 5 Dec 2003 09:29:30 GMT > Organization: Spin Internetworking > Message-ID: > Reply-To: furioun at spin.it > NNTP-Posting-Host: photon.spin.it > > After several months of spam support including routing of hijacked IP > blocks, without apparent traces of non-abuse related IP traffic, our > backbone is now stopping the exchange of IP packets with AS27595, > currently announcing the following blocks: > > Network DNSBL Upstreams > --------------- ----- ------------------ > 65.124.21.0/24 4474 > 66.250.145.0/24 S2489 22934 > 67.130.99.0/24 4474 > 69.1.78.0/24 S2783 4474, 22934 > 69.31.64.0/20 S2453 4474 > 69.31.76.0/22 S2453 4474, 30371 > 69.50.160.0/20 S2489 4474, 22934, 30371 > 69.50.176.0/20 S2489 4474, 22934, 30371 > > AS4474 Global Village Communication, Inc. > AS22934 E Broadband Now Inc. > AS30371 nLayer Communications, Inc. > > We are currently considering an extension of this measure to the > three entities above, which also seem to appear repeatedly in connection > with network abuses and with very little, if any, legitimate traffic > with our customers. > > furio ercolessi > Spin.it ---Rsk From fergdawgster at gmail.com Wed Sep 24 21:08:23 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 24 Sep 2008 19:08:23 -0700 Subject: Atrivo/Intercage In-Reply-To: <48DAF127.2070902@cox.net> References: <20080924175449.7907ED80@resin13.mta.everyone.net> <1222307420.20200.1353.camel@petrie.sacredspiral.co.uk> <75cb24520809241858la951898v17ce14558b815731@mail.gmail.com> <48DAF127.2070902@cox.net> Message-ID: <6cd462c00809241908j6f858d42l68c6f54133b0dbd8@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Sep 24, 2008 at 7:02 PM, Laurence F. Sheldon, Jr. wrote: > > Apprehending criminals is the Law's job. > > My job is making sure they don't deal that sh*t in MY parkinglot. > Exactly. It could be argued (since _is_ the North American Network Operators Group) that pushing this sort of criminal activity _out_ of North America is a good First Step.... to be able to better manage the situation. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI2vKTq1pz9mNUZTMRAhK3AJ41SKDLnteNVSqjoNlLDMNutY3sNACgu3O8 EZT2NSbpVvHcd7XRgjBAAQA= =bmQI -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From bambenek at gmail.com Wed Sep 24 21:20:59 2008 From: bambenek at gmail.com (John Bambenek) Date: Wed, 24 Sep 2008 21:20:59 -0500 Subject: the Intercage mess In-Reply-To: <20080924133743.944847809@relayer.avian.org> References: <20080924133743.944847809@relayer.avian.org> Message-ID: <48DAF58B.8030507@gmail.com> When there is no law to speak of all that is left is tribal justice. That doesn't make the problem the tribe, the real problem is the lawlessness. It would much rather prefer that we find a way to not let ISPs externalize their "costs" in taking money from bad people who do nothing but cause problems for the rest of us. j *Hobbit* wrote: > While it's good to see some community effort going toward slapping > a lid on misbehaving sources, how about a little consistency in > the bigger picture? > > Consider this sort of scenario: An ISP allows its infrastructure > to emit spam and host compromised machines to harbor malware and > facilitate crime and botnets. Its abuse mailbox is a black hole > that is provably ignored. All reasonable efforts to get the problem > fixed fail. Network operators band together and deroute the ISP's > blocks, forcing them to either clean up their act or find something > else to do with their time. Internet death penalty, simple enough. > > If this happened to some of the other major sources of crap that > I'm thinking of, it would make the freaking NATIONAL NEWS. Where's > the BACKBONE to go after the real high-volume sources, rather than > continuing to kick sand in the face of some podunk little guy who > can no longer defend himself? > > _H* > > From randy at psg.com Wed Sep 24 21:24:17 2008 From: randy at psg.com (Randy Bush) Date: Thu, 25 Sep 2008 11:24:17 +0900 Subject: the Intercage mess In-Reply-To: <48DAF58B.8030507@gmail.com> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> Message-ID: <48DAF651.70608@psg.com> John Bambenek wrote: > When there is no law to speak of all that is left is tribal justice. this way lies lynch mobs shall we at least apply a vernier of civilization? randy From LarrySheldon at cox.net Wed Sep 24 21:28:11 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Wed, 24 Sep 2008 21:28:11 -0500 Subject: the Intercage mess In-Reply-To: <48DAF651.70608@psg.com> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> Message-ID: <48DAF73B.8010102@cox.net> Randy Bush wrote: > shall we at least apply a vernier of civilization? A veneer would be ever better, unless you are into fine tuning. From fergdawgster at gmail.com Wed Sep 24 21:28:31 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 24 Sep 2008 19:28:31 -0700 Subject: the Intercage mess In-Reply-To: <48DAF651.70608@psg.com> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> Message-ID: <6cd462c00809241928t3cfe214fn93ed7f38688112f7@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Sep 24, 2008 at 7:24 PM, Randy Bush wrote: > John Bambenek wrote: >> When there is no law to speak of all that is left is tribal justice. > > this way lies lynch mobs > > shall we at least apply a vernier of civilization? > I think that _more_than_reasonable_ background research, historical record, etc. have met the qualifications of "civilized vernier". The outcry was, and is not, arbitrary. $.02, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI2vdGq1pz9mNUZTMRAhIHAKC4RCmAZy0iC9rlWwIqxW2ClN5/dwCgjVFo 4EqEoVLhbpxEfgA3iMWCeZg= =Uy/7 -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From surfer at mauigateway.com Wed Sep 24 21:39:54 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 24 Sep 2008 19:39:54 -0700 Subject: Atrivo/Intercage Message-ID: <20080924193954.79071DD4@resin13.mta.everyone.net> --- nenolod at systeminplace.net wrote: From: William Pitcock > I didn't whine. No, but others have, and it isn't helpful towards resolving this problem. ---------------------------------------- I also wrote you that in private, but you decided to make it public without asking me. That type of action makes your position less valid. scott From nenolod at systeminplace.net Wed Sep 24 21:52:36 2008 From: nenolod at systeminplace.net (William Pitcock) Date: Wed, 24 Sep 2008 21:52:36 -0500 Subject: the Intercage mess In-Reply-To: <6cd462c00809241928t3cfe214fn93ed7f38688112f7@mail.gmail.com> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> <6cd462c00809241928t3cfe214fn93ed7f38688112f7@mail.gmail.com> Message-ID: <1222311156.20200.1364.camel@petrie.sacredspiral.co.uk> On Wed, 2008-09-24 at 19:28 -0700, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Wed, Sep 24, 2008 at 7:24 PM, Randy Bush wrote: > > > John Bambenek wrote: > >> When there is no law to speak of all that is left is tribal justice. > > > > this way lies lynch mobs > > > > shall we at least apply a vernier of civilization? > > > > I think that _more_than_reasonable_ background research, historical record, > etc. have met the qualifications of "civilized vernier". The outcry was, > and is not, arbitrary. No, but forcing them offline now that they are taking a new approach to handling abuse is ridiculous. Intercage are reaching out to the anti-abuse community and yet some people on NANOG keep interfering with the cleanup process. How do you expect them to clean up their network and return to normal operations (with considerably less abuse) if it keeps being disconnected? The shit isn't even there anymore. These kids have moved it elsewhere. Intercage have learned their lesson, just leave them alone and let the people who have *real* problems (e.g. me, Andrew Kirch of AHBL, Spamhaus, Gadi, etc.) with Intercage deal with this. If anyone has any issue with Atrivo/Intercage that still needs rectification: please contact me or Andrew Kirch offlist and we will bring it to their attention. We have contact with these people, and they are listening and taking action to clean up their network. If not, then please stop with this thread. It's not helpful, and it's certaintly counter-productive. William From nenolod at systeminplace.net Wed Sep 24 21:53:29 2008 From: nenolod at systeminplace.net (William Pitcock) Date: Wed, 24 Sep 2008 21:53:29 -0500 Subject: Atrivo/Intercage In-Reply-To: <20080924193954.79071DD4@resin13.mta.everyone.net> References: <20080924193954.79071DD4@resin13.mta.everyone.net> Message-ID: <1222311209.20200.1366.camel@petrie.sacredspiral.co.uk> Hi, On Wed, 2008-09-24 at 19:39 -0700, Scott Weeks wrote: > > --- nenolod at systeminplace.net wrote: > From: William Pitcock > > > I didn't whine. > > No, but others have, and it isn't helpful towards resolving this > problem. > ---------------------------------------- > > > I also wrote you that in private, but you decided to make it public without asking me. That type of action makes your position less valid. I apologize, I didn't notice that it was private. William From fergdawgster at gmail.com Wed Sep 24 21:58:34 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 24 Sep 2008 19:58:34 -0700 Subject: the Intercage mess In-Reply-To: <1222311156.20200.1364.camel@petrie.sacredspiral.co.uk> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> <6cd462c00809241928t3cfe214fn93ed7f38688112f7@mail.gmail.com> <1222311156.20200.1364.camel@petrie.sacredspiral.co.uk> Message-ID: <6cd462c00809241958w103ae971ya5038af0aa88975b@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Sep 24, 2008 at 7:52 PM, William Pitcock wrote: > On Wed, 2008-09-24 at 19:28 -0700, Paul Ferguson wrote: >> I think that _more_than_reasonable_ background research, historical >> record, etc. have met the qualifications of "civilized vernier". The >> outcry was, and is not, arbitrary. > > No, but forcing them offline now that they are taking a new approach to > handling abuse is ridiculous. > No -- I think that after 5 years of malicious activity, it was overdue. I'm sorry, but your efforts to get the last word here are in vain. Cheers, - - ferg p.s. And by the way, whether the badness has actually been purged from Atrivo/Intercage's IP address space remains to be seen -- previous similar claims have all been false. Time will tell -- may eyes are watching. -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI2v5Oq1pz9mNUZTMRAhaHAJ46OFbpGDap70pAEHlzLwOCiJpRhgCfRgM1 4Riwi5G0vWvtZZWyYt9mgKw= =4BP6 -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From nenolod at systeminplace.net Wed Sep 24 22:10:42 2008 From: nenolod at systeminplace.net (William Pitcock) Date: Wed, 24 Sep 2008 22:10:42 -0500 Subject: the Intercage mess In-Reply-To: <6cd462c00809241958w103ae971ya5038af0aa88975b@mail.gmail.com> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> <6cd462c00809241928t3cfe214fn93ed7f38688112f7@mail.gmail.com> <1222311156.20200.1364.camel@petrie.sacredspiral.co.uk> <6cd462c00809241958w103ae971ya5038af0aa88975b@mail.gmail.com> Message-ID: <1222312242.20200.1376.camel@petrie.sacredspiral.co.uk> On Wed, 2008-09-24 at 19:58 -0700, Paul Ferguson wrote: > On Wed, Sep 24, 2008 at 7:52 PM, William Pitcock > wrote: > > > On Wed, 2008-09-24 at 19:28 -0700, Paul Ferguson wrote: > > >> I think that _more_than_reasonable_ background research, historical > >> record, etc. have met the qualifications of "civilized vernier". The > >> outcry was, and is not, arbitrary. > > > > No, but forcing them offline now that they are taking a new approach to > > handling abuse is ridiculous. > > > > No -- I think that after 5 years of malicious activity, it was overdue. I said _new_ approach. I agree that it was overdue, but they are being cooperative with the anti-abuse community, so I think it is appropriate to give them an opportunity to deliver on their promise. If they fail, then shut them off again. > I'm sorry, but your efforts to get the last word here are in vain. > > Cheers, > > - - ferg > > p.s. And by the way, whether the badness has actually been purged from > Atrivo/Intercage's IP address space remains to be seen -- previous similar > claims have all been false. Time will tell -- may eyes are watching. Esthost are nullrouted as of this morning. Even their administrative network is nullrouted. I think that is a good indication. As I said, if you have any still open issues, please let me know. I am talking to these people and they are listening. William From fergdawgster at gmail.com Wed Sep 24 22:14:16 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 24 Sep 2008 20:14:16 -0700 Subject: the Intercage mess In-Reply-To: <1222312242.20200.1376.camel@petrie.sacredspiral.co.uk> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> <6cd462c00809241928t3cfe214fn93ed7f38688112f7@mail.gmail.com> <1222311156.20200.1364.camel@petrie.sacredspiral.co.uk> <6cd462c00809241958w103ae971ya5038af0aa88975b@mail.gmail.com> <1222312242.20200.1376.camel@petrie.sacredspiral.co.uk> Message-ID: <6cd462c00809242014h3d5bd2bev61c8c710f0b4d40a@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Sep 24, 2008 at 8:10 PM, William Pitcock wrote: > > I said _new_ approach. I agree that it was overdue, but they are being > cooperative with the anti-abuse community, so I think it is appropriate > to give them an opportunity to deliver on their promise. If they fail, > then shut them off again. That sounds reasonable to me. > > Esthost are nullrouted as of this morning. Even their administrative > network is nullrouted. > That's only because after they tried to set up shop in NL, they were outed. As I said, many eyes are watching -- and not just Atrivo/Intercage either. Cheers, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI2wIBq1pz9mNUZTMRAjtDAKCHaW9XvIUoxbKLXNK3MsvKpPAyLQCeIM4b io/ntq8rb6mcj6w+ZCvkGZQ= =0Xnm -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From bpfankuch at cpgreeley.com Wed Sep 24 22:24:15 2008 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Wed, 24 Sep 2008 21:24:15 -0600 Subject: the Intercage mess In-Reply-To: <6cd462c00809242014h3d5bd2bev61c8c710f0b4d40a@mail.gmail.com> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> <6cd462c00809241928t3cfe214fn93ed7f38688112f7@mail.gmail.com> <1222311156.20200.1364.camel@petrie.sacredspiral.co.uk> <6cd462c00809241958w103ae971ya5038af0aa88975b@mail.gmail.com> <1222312242.20200.1376.camel@petrie.sacredspiral.co.uk> <6cd462c00809242014h3d5bd2bev61c8c710f0b4d40a@mail.gmail.com> Message-ID: <01759D50DC387C45A018FE1817CE27D751CBA4C0B5@CPExchange1.cpgreeley.com> Ok, as this seems to have turned into a pissing match, can we slow this down a bit? 50+ emails a day for a week and nothing good of it? Yes yes we have purged the internet of evil. Instead of all the bickering and finger pointing, let's do something worthwhile like helping identify the root of the problem. So abuse@ wasn't monitored previously. It will be soon if you would give it a chance. They are working on it, so I saw we lighten up on the pitchfork gig. Everyone put down the torches and stop screaming witch. Let's give them some time to actually act on a lot of the information they are getting from anti-abuse, and anything usable they might have been able to filter out of this flood of a week on nanog. Perhaps we could revisit this in a month, not as a bash and finger point but more as a "hey here is one more thing you could do to help keep your network clean." -----Original Message----- From: Paul Ferguson [mailto:fergdawgster at gmail.com] Sent: Wednesday, September 24, 2008 9:14 PM To: William Pitcock Cc: nanog at nanog.org Subject: Re: the Intercage mess -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Sep 24, 2008 at 8:10 PM, William Pitcock wrote: > > I said _new_ approach. I agree that it was overdue, but they are being > cooperative with the anti-abuse community, so I think it is appropriate > to give them an opportunity to deliver on their promise. If they fail, > then shut them off again. That sounds reasonable to me. > > Esthost are nullrouted as of this morning. Even their administrative > network is nullrouted. > That's only because after they tried to set up shop in NL, they were outed. As I said, many eyes are watching -- and not just Atrivo/Intercage either. Cheers, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI2wIBq1pz9mNUZTMRAjtDAKCHaW9XvIUoxbKLXNK3MsvKpPAyLQCeIM4b io/ntq8rb6mcj6w+ZCvkGZQ= =0Xnm -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From fergdawgster at gmail.com Wed Sep 24 22:30:46 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 24 Sep 2008 20:30:46 -0700 Subject: the Intercage mess In-Reply-To: <01759D50DC387C45A018FE1817CE27D751CBA4C0B5@CPExchange1.cpgreeley.com> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> <6cd462c00809241928t3cfe214fn93ed7f38688112f7@mail.gmail.com> <1222311156.20200.1364.camel@petrie.sacredspiral.co.uk> <6cd462c00809241958w103ae971ya5038af0aa88975b@mail.gmail.com> <1222312242.20200.1376.camel@petrie.sacredspiral.co.uk> <6cd462c00809242014h3d5bd2bev61c8c710f0b4d40a@mail.gmail.com> <01759D50DC387C45A018FE1817CE27D751CBA4C0B5@CPExchange1.cpgreeley.com> Message-ID: <6cd462c00809242030o2ec6550at2a90b9211ab4729f@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Sep 24, 2008 at 8:24 PM, Blake Pfankuch wrote: > Ok, as this seems to have turned into a pissing match, can we slow this > down a bit? 50+ emails a day for a week and nothing good of it? Yes yes > we have purged the internet of evil. Instead of all the bickering and > finger pointing, let's do something worthwhile like helping identify the > root of the problem. So abuse@ wasn't monitored previously. It will be > soon if you would give it a chance. They are working on it, so I saw we > lighten up on the pitchfork gig. Everyone put down the torches and stop > screaming witch. Let's give them some time to actually act on a lot of > the information they are getting from anti-abuse, and anything usable > they might have been able to filter out of this flood of a week on nanog. > Perhaps we could revisit this in a month, not as a bash and finger point > but more as a "hey here is one more thing you could do to help keep your > network clean." > If you really think this was a simple matter of "...not monitoring abuse@ mailboxes..." then you are highly misinformed. Nothing personal. This will (hopefully) be my last post in this thread. Cheers, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI2wXZq1pz9mNUZTMRAtfuAJ9rd6e8QxOE2cVDQpp7WUkiTnACvACeNAuN PU+E0C/8RPwNEG+JTN0rOWA= =bP4o -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From stephen at sprunk.org Wed Sep 24 22:35:29 2008 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 24 Sep 2008 22:35:29 -0500 Subject: the Intercage mess In-Reply-To: <1222311156.20200.1364.camel@petrie.sacredspiral.co.uk> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> <6cd462c00809241928t3cfe214fn93ed7f38688112f7@mail.gmail.com> <1222311156.20200.1364.camel@petrie.sacredspiral.co.uk> Message-ID: <48DB0701.6030501@sprunk.org> William Pitcock wrote: > On Wed, 2008-09-24 at 19:28 -0700, Paul Ferguson wrote: > >> On Wed, Sep 24, 2008 at 7:24 PM, Randy Bush wrote: >> >>> John Bambenek wrote: >>> >>>> When there is no law to speak of all that is left is tribal justice. >>>> >>> this way lies lynch mobs >>> >>> shall we at least apply a vernier of civilization >> I think that _more_than_reasonable_ background research, historical record, etc. have met the qualifications of "civilized vernier". The outcry was, and is not, arbitrary. >> > > No, but forcing them offline now that they are taking a new approach to > handling abuse is ridiculous. > > Intercage are reaching out to the anti-abuse community and yet some people on NANOG keep interfering with the cleanup process. How do you expect them to clean up their network and return to normal operations (with considerably less abuse) if it keeps being disconnected? > > The shit isn't even there anymore. These kids have moved it elsewhere. Intercage have learned their lesson, just leave them alone and let the people who have *real* problems (e.g. me, Andrew Kirch of AHBL, Spamhaus, Gadi, etc.) with Intercage deal with this. > They _claim_ they have learned their lesson and cleaned up their act. However, that does not erase the _years_ that they knew what was going on and happily took miscreants' money for polluting the commons. The police and courts are impotent, so it falls to the victims to take action. I hate lynch mobs as much as the next guy, but the law _does_ allow people to defend themselves and protect themselves from future harm by proven bad actors. They could be lying; we have no proof they're not, so given their track record, we must assume they are. What's to stop them from next week going back to the folks they've disconnected and taking their money again, again abusing the community. Even if they're not lying, application of the Death Penalty, as obviously justified in this case, is the _only_ way to discourage others from doing the same thing by instilling the fear of the same consequences. S From randy at psg.com Wed Sep 24 22:36:58 2008 From: randy at psg.com (Randy Bush) Date: Thu, 25 Sep 2008 12:36:58 +0900 Subject: the NANOG mess In-Reply-To: <6cd462c00809242030o2ec6550at2a90b9211ab4729f@mail.gmail.com> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> <6cd462c00809241928t3cfe214fn93ed7f38688112f7@mail.gmail.com> <1222311156.20200.1364.camel@petrie.sacredspiral.co.uk> <6cd462c00809241958w103ae971ya5038af0aa88975b@mail.gmail.com> <1222312242.20200.1376.camel@petrie.sacredspiral.co.uk> <6cd462c00809242014h3d5bd2bev61c8c710f0b4d40a@mail.gmail.com> <01759D50DC387C45A018FE1817CE27D751CBA4C0B5@CPExchange1.cpgreeley.com> <6cd462c00809242030o2ec6550at2a90b9211ab4729f@mail.gmail.com> Message-ID: <48DB075A.2030707@psg.com> : * ^Return-Path:.*nanog-bounces * ^Subject:.*Intercage $TRASH enough already randy From virendra.rode at gmail.com Wed Sep 24 22:53:04 2008 From: virendra.rode at gmail.com (virendra rode) Date: Wed, 24 Sep 2008 20:53:04 -0700 Subject: puck outage this am. Message-ID: <48DB0B20.9010803@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, You may or may not have noticed puck.nether.net (hosting outages.org mailing list) suffered an outage this am. This was caused due to a file system issue (possible inconsistence state) on a fairly large (1tb) filesystem which caused services on puck to be unresponsive. Many thanks to Jared Mauch in addressing this issue. Like always, appreciate your feedback and your constructive criticism. regards, /virendra -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI2wsgpbZvCIJx1bcRArpUAJsECd19nRQs06wkgvnfS3Xhk2TvOQCghhTC OyRIHk8YHPR72l+WRmh15qU= =fy4U -----END PGP SIGNATURE----- From brunner at nic-naa.net Wed Sep 24 23:14:55 2008 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Thu, 25 Sep 2008 00:14:55 -0400 Subject: the Intercage mess In-Reply-To: <48DAF651.70608@psg.com> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> Message-ID: <48DB103F.50202@nic-naa.net> Randy Bush wrote: > John Bambenek wrote: > >> When there is no law to speak of all that is left is tribal justice. >> > > this way lies lynch mobs > > shall we at least apply a vernier of civilization? > > randy > > > > While I appreciate the points both you and John are attempting to make, as someone who is engaged in tribal government, and peripheral to the tribal legal community (I ran the TribalLaw list for years), I suggest there are rhetorical alternatives. You may be amused that in Ex Parte Crow Dog, the USSC found in 1883 that it had no jurisdiction over the tribal court which tried, convicted, and sentenced Crow Dog for the killing of Spotted Tail. The sentence for that homicide (a political one in the context of factionalism during the onset of the Brule Sioux captivity) imposed by the tribal court was not death by hanging (payment was made to the tiospaye (kin) of the former, treaty signing principal chief). The following year Congress enacted the Major Crimes Act so that "an eye for an eye" would be the law in Indian Country. Note, not only did this extend Judeo-Christian reciprocity to offenses between tribal members, it also guaranteed death to any Indians who punished a "treaty signer" for providing the legal excuse for private and non-member expropriation of collectively held land. More modernly, tribal courts seem to be better at substance abuse sentencing, based on outcomes, than non-tribal courts. I know some tribal jurists who'd be tickled pink to be asked to talk to a room of network people on tribal legal institutions and issues at Minneapolis. I've been following this because of the trust anchor problem discussed elsewhere for address and AS allocation, and the NS and A record manifestation of some exploits that require sets of addresses, though not necessarily colocated within one or few address allocations or routed to one or few ASs, again, discussed elsewhere. Cheers, Eric From fergdawgster at gmail.com Wed Sep 24 23:50:23 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 24 Sep 2008 21:50:23 -0700 Subject: the Intercage mess In-Reply-To: <1222312242.20200.1376.camel@petrie.sacredspiral.co.uk> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> <6cd462c00809241928t3cfe214fn93ed7f38688112f7@mail.gmail.com> <1222311156.20200.1364.camel@petrie.sacredspiral.co.uk> <6cd462c00809241958w103ae971ya5038af0aa88975b@mail.gmail.com> <1222312242.20200.1376.camel@petrie.sacredspiral.co.uk> Message-ID: <6cd462c00809242150m759fac9bw2fcf54d011a4489e@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Sep 24, 2008 at 8:10 PM, William Pitcock wrote: > > Esthost are nullrouted as of this morning. Even their administrative > network is nullrouted. > > I think that is a good indication. As I said, if you have any still open > issues, please let me know. I am talking to these people and they are > listening. > Okay. Riddle me this: Why is Intercage hosting Cernel.net? cernel.net -A-> 69.50.176.227 AS | IP | AS Name 27595 | 69.50.176.227 | INTERCAGE - InterCage, Inc. I guess this was just a mistake, right? Oh, and of course, Cernel.net was registered with... wait for it... Estdoamins. And this was very recent. Go figure. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI2xh+q1pz9mNUZTMRAqxeAJ407rL+740CN6kta9wqsxfH1JiK2QCgh7Lz iUtH/4wd60YrPGHeQW6JORk= =6a8a -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From fergdawgster at gmail.com Thu Sep 25 00:41:07 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 24 Sep 2008 22:41:07 -0700 Subject: the Intercage mess In-Reply-To: <6cd462c00809242150m759fac9bw2fcf54d011a4489e@mail.gmail.com> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> <6cd462c00809241928t3cfe214fn93ed7f38688112f7@mail.gmail.com> <1222311156.20200.1364.camel@petrie.sacredspiral.co.uk> <6cd462c00809241958w103ae971ya5038af0aa88975b@mail.gmail.com> <1222312242.20200.1376.camel@petrie.sacredspiral.co.uk> <6cd462c00809242150m759fac9bw2fcf54d011a4489e@mail.gmail.com> Message-ID: <6cd462c00809242241t5d24e5barbfb363c492facdaf@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Sep 24, 2008 at 9:50 PM, Paul Ferguson wrote: > > Why is Intercage hosting Cernel.net? > > cernel.net -A-> 69.50.176.227 > > AS | IP | AS Name > 27595 | 69.50.176.227 | INTERCAGE - InterCage, Inc. > > I guess this was just a mistake, right? > > Oh, and of course, Cernel.net was registered with... wait for it... > Estdoamins. > > And this was very recent. > > Go figure. > A bit more: A glance at DNS relationships between Intercage, Cernel, and Rove Digital are apparent when digging around on DNS dependencies -- lookup cernel.net at the BFK DNSLogger: http://www.bfk.de/bfk_dnslogger.html ns2.protectdetails.com A 69.50.176.229 ns1.esthost.com A 69.50.176.229 ens1.esthost.com A 69.50.176.229 ns2.esthost.com A 69.50.176.229 ns2.cernel.net A 69.50.176.229 AS | IP | AS Name 27595 | 69.50.176.229 | INTERCAGE - InterCage, Inc. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI2yRuq1pz9mNUZTMRAtubAJ9btg6xQbS335ZgrUazSvd09uDfgQCcCvxc ULZ9X4sFJDXWgbYVp06+bXY= =RJP8 -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From fergdawgster at gmail.com Thu Sep 25 00:45:38 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 24 Sep 2008 22:45:38 -0700 Subject: the Intercage mess In-Reply-To: <6cd462c00809242241t5d24e5barbfb363c492facdaf@mail.gmail.com> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> <6cd462c00809241928t3cfe214fn93ed7f38688112f7@mail.gmail.com> <1222311156.20200.1364.camel@petrie.sacredspiral.co.uk> <6cd462c00809241958w103ae971ya5038af0aa88975b@mail.gmail.com> <1222312242.20200.1376.camel@petrie.sacredspiral.co.uk> <6cd462c00809242150m759fac9bw2fcf54d011a4489e@mail.gmail.com> <6cd462c00809242241t5d24e5barbfb363c492facdaf@mail.gmail.com> Message-ID: <6cd462c00809242245w531d8c2ar646dcc8aa59db691@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Sep 24, 2008 at 10:41 PM, Paul Ferguson wrote: >> Why is Intercage hosting Cernel.net? >> >> cernel.net -A-> 69.50.176.227 >> >> AS | IP | AS Name >> 27595 | 69.50.176.227 | INTERCAGE - InterCage, Inc. >> >> I guess this was just a mistake, right? >> >> Oh, and of course, Cernel.net was registered with... wait for it... >> Estdoamins. >> >> And this was very recent. >> >> Go figure. >> > > A bit more: > > A glance at DNS relationships between Intercage, Cernel, and Rove Digital > are apparent when digging around on DNS dependencies -- lookup cernel.net > at the BFK DNSLogger: > > http://www.bfk.de/bfk_dnslogger.html > > ns2.protectdetails.com A 69.50.176.229 > ns1.esthost.com A 69.50.176.229 > ens1.esthost.com A 69.50.176.229 > ns2.esthost.com A 69.50.176.229 > ns2.cernel.net A 69.50.176.229 > > AS | IP | AS Name > 27595 | 69.50.176.229 | INTERCAGE - InterCage, Inc. > Oops. I forgot to add: ns2.spb-traffic.com A 69.50.176.227 ns2.site-people.com A 69.50.176.227 ns2.estsecure.com A 69.50.176.227 rovedigital.com A 69.50.176.227 ns2.rovedigital.com A 69.50.176.227 ans2.rovedigital.com A 69.50.176.227 dev.rovedigital.com A 69.50.176.227 ns2.mega-all.com A 69.50.176.227 ns2.cernel.net A 69.50.176.227 alpha.cernel.net A 69.50.176.227 beta.cernel.net A 69.50.176.227 - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI2yV4q1pz9mNUZTMRArRhAJ43UyY2xSIAWrFsRorN3vIgFB+U2QCgqaRa gwPpHcQ5p1pwOAr7IBTs7xg= =gT6R -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From vixie at isc.org Thu Sep 25 00:47:32 2008 From: vixie at isc.org (Paul Vixie) Date: Thu, 25 Sep 2008 05:47:32 +0000 Subject: obvious intent (Re: the Intercage mess) In-Reply-To: <1222311156.20200.1364.camel@petrie.sacredspiral.co.uk> (William Pitcock's message of "Wed\, 24 Sep 2008 21\:52\:36 -0500") References: <1222311156.20200.1364.camel@petrie.sacredspiral.co.uk> Message-ID: nenolod at systeminplace.net (William Pitcock) writes: > ... forcing them offline now that they are taking a new approach to > handling abuse is ridiculous. ... renaming, renumbering, and rehoming the darkest parts of their empire is not a new approach to handling abuse, it's the most common thing that gray networks do when faced with disconnection, because it's the thing that looks most like protective colouration for them and it's the thing that looks most like plausible deniability for their (new?) providers. so, now begins the search for the line that mustn't be crossed. if they have N spamming customer or M "captured" machines running C&C and they disconnect such customers after P warnings or Q days, then will the community still rise up in arms and if so will that still be enough negativity to cause their (new?) provider to lose connectivity? if not, then what about P-1 or Q+1 or M*2 or N/2? discovering the process by which N, M, P, and Q are discovered, will be even uglier than everything we've seen on this topic to date. i advise those interested in the truth about a network's long term reputation to get their information from friends and professionals in the security business, or even google, but not nanog. or just refuse to suspend disbelief, and ask why someone's apparently new approach to handling abuse, the "turning over a new leaf", happened so many years into the game. what was their obvious intent, if not monetizing the uncertainty and inertia of the networks whose connectivity they depend on? -- Paul Vixie From jrhett at netconsonance.com Thu Sep 25 00:48:41 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Wed, 24 Sep 2008 22:48:41 -0700 Subject: a vernier of civilization... In-Reply-To: <48DAF651.70608@psg.com> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> Message-ID: <58B1BC8C-19D5-46A1-A313-9A3B04F8112C@netconsonance.com> On Sep 24, 2008, at 7:24 PM, Randy Bush wrote: > this way lies lynch mobs > shall we at least apply a vernier of civilization? Randy, I would agree if anything less had ever been effective. If you have a better idea, please explain to the rest of us. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From nenolod at systeminplace.net Thu Sep 25 01:04:50 2008 From: nenolod at systeminplace.net (William Pitcock) Date: Thu, 25 Sep 2008 01:04:50 -0500 Subject: the Intercage mess In-Reply-To: <6cd462c00809242150m759fac9bw2fcf54d011a4489e@mail.gmail.com> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> <6cd462c00809241928t3cfe214fn93ed7f38688112f7@mail.gmail.com> <1222311156.20200.1364.camel@petrie.sacredspiral.co.uk> <6cd462c00809241958w103ae971ya5038af0aa88975b@mail.gmail.com> <1222312242.20200.1376.camel@petrie.sacredspiral.co.uk> <6cd462c00809242150m759fac9bw2fcf54d011a4489e@mail.gmail.com> Message-ID: <1222322690.20200.1387.camel@petrie.sacredspiral.co.uk> On Wed, 2008-09-24 at 21:50 -0700, Paul Ferguson wrote: > On Wed, Sep 24, 2008 at 8:10 PM, William Pitcock > wrote: > > > > > Esthost are nullrouted as of this morning. Even their administrative > > network is nullrouted. > > > > I think that is a good indication. As I said, if you have any still open > > issues, please let me know. I am talking to these people and they are > > listening. > > > > Okay. Riddle me this: > > Why is Intercage hosting Cernel.net? > > cernel.net -A-> 69.50.176.227 > > AS | IP | AS Name > 27595 | 69.50.176.227 | INTERCAGE - InterCage, Inc. Except that they are not: it is offline. --- 69.50.176.227 ping statistics ----- 15 packets transmitted, 0 received, 100% packet loss, time 14008ms nenolod at petrie:~$ wget http://69.50.176.227/ ?2008-09-25 00:56:54-- http://69.50.176.227/ Connecting to 69.50.176.227:80... failed: Connection timed out. Retrying. --2008-09-25 01:00:04-- (try: 2) http://69.50.176.227/ Connecting to 69.50.176.227:80... failed: Connection timed out. Retrying. --2008-09-25 01:03:15-- (try: 3) http://69.50.176.227/ Connecting to 69.50.176.227:80... ^C 69.50.176.0/24 is nullrouted by Intercage itself and the equipment is powered off. Thanks for playing, but next time you might want to point out something that is actually online. It will certaintly make your argument be more fact-based. Or maybe my problem is that I have a "fact-based world view". William From fergdawgster at gmail.com Thu Sep 25 01:10:27 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 24 Sep 2008 23:10:27 -0700 Subject: the Intercage mess In-Reply-To: <1222322690.20200.1387.camel@petrie.sacredspiral.co.uk> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> <6cd462c00809241928t3cfe214fn93ed7f38688112f7@mail.gmail.com> <1222311156.20200.1364.camel@petrie.sacredspiral.co.uk> <6cd462c00809241958w103ae971ya5038af0aa88975b@mail.gmail.com> <1222312242.20200.1376.camel@petrie.sacredspiral.co.uk> <6cd462c00809242150m759fac9bw2fcf54d011a4489e@mail.gmail.com> <1222322690.20200.1387.camel@petrie.sacredspiral.co.uk> Message-ID: <6cd462c00809242310l3cf6033dsf7c5cdbcb101ee10@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Sep 24, 2008 at 11:04 PM, William Pitcock wrote: > > Thanks for playing, but next time you might want to point out something > that is actually online. It will certaintly make your argument be more > fact-based. > > Or maybe my problem is that I have a "fact-based world view". > No, than you for playing. When the DNS dependencies are removed, we can all play Kum Ba Yah. Don't toss me an excuse and expect mileage. Fix it. Then we can all play nice. Cheers! - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI2ytOq1pz9mNUZTMRAiqYAKDbKSez0EH6mPLxALhPlt8m7K+zSgCggCxF NjcGfvQ78hurxx2tEgBGhNQ= =fxML -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From fergdawgster at gmail.com Thu Sep 25 01:46:08 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 24 Sep 2008 23:46:08 -0700 Subject: the Intercage mess In-Reply-To: <6cd462c00809242245w531d8c2ar646dcc8aa59db691@mail.gmail.com> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> <6cd462c00809241928t3cfe214fn93ed7f38688112f7@mail.gmail.com> <1222311156.20200.1364.camel@petrie.sacredspiral.co.uk> <6cd462c00809241958w103ae971ya5038af0aa88975b@mail.gmail.com> <1222312242.20200.1376.camel@petrie.sacredspiral.co.uk> <6cd462c00809242150m759fac9bw2fcf54d011a4489e@mail.gmail.com> <6cd462c00809242241t5d24e5barbfb363c492facdaf@mail.gmail.com> <6cd462c00809242245w531d8c2ar646dcc8aa59db691@mail.gmail.com> Message-ID: <6cd462c00809242346r3c7cac6id755e61ffab3c4a4@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Sep 24, 2008 at 10:45 PM, Paul Ferguson wrote: >>> Why is Intercage hosting Cernel.net? >>> >>> cernel.net -A-> 69.50.176.227 >>> >>> AS | IP | AS Name >>> 27595 | 69.50.176.227 | INTERCAGE - InterCage, Inc. >>> >>> I guess this was just a mistake, right? >>> >>> Oh, and of course, Cernel.net was registered with... wait for it... >>> Estdoamins. >>> >>> And this was very recent. >>> >>> Go figure. >>> >> >> A bit more: >> >> A glance at DNS relationships between Intercage, Cernel, and Rove >> Digital are apparent when digging around on DNS dependencies -- lookup >> cernel.net at the BFK DNSLogger: >> >> http://www.bfk.de/bfk_dnslogger.html >> >> ns2.protectdetails.com A 69.50.176.229 >> ns1.esthost.com A 69.50.176.229 >> ens1.esthost.com A 69.50.176.229 >> ns2.esthost.com A 69.50.176.229 >> ns2.cernel.net A 69.50.176.229 >> >> AS | IP | AS Name >> 27595 | 69.50.176.229 | INTERCAGE - InterCage, Inc. >> > > > Oops. I forgot to add: > > ns2.spb-traffic.com A 69.50.176.227 > ns2.site-people.com A 69.50.176.227 > ns2.estsecure.com A 69.50.176.227 > rovedigital.com A 69.50.176.227 > ns2.rovedigital.com A 69.50.176.227 > ans2.rovedigital.com A 69.50.176.227 > dev.rovedigital.com A 69.50.176.227 > ns2.mega-all.com A 69.50.176.227 > ns2.cernel.net A 69.50.176.227 > alpha.cernel.net A 69.50.176.227 > beta.cernel.net A 69.50.176.227 > Just in case anyone needs a refresher on Rove Digital: http://voices.washingtonpost.com/securityfix/2008/09/estdomains_a_sordid_hi story_an.html - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI2zOrq1pz9mNUZTMRAmjeAKDrsXVJuhk1Um8/92cjg51xDUrXOACeJlC0 7rhjnPNtWrPNPEFR+vG4i+k= =SMP+ -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From noel.butler at ausics.net Thu Sep 25 02:11:32 2008 From: noel.butler at ausics.net (Noel Butler) Date: Thu, 25 Sep 2008 17:11:32 +1000 Subject: MTA Survey Message-ID: <1222326691.29270.10.camel@roswell.ausics.net> Some of you may recall back in late 2006 we ran an international poll on MTA's, where over a period of several months and 12 and half thousands voters later, Sendmail was declared king, followed by Qmail, then Exim then Postfix, Exchange and some lesser know immaterials ... Well folks we have wiped the ol one clean and asking for votes again as alot may have changed in nearly 2 years, If you want to case your vote, feel free to at http://polls.ausics.net/v3.php All the best. From karnaugh at karnaugh.za.net Thu Sep 25 02:25:56 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Thu, 25 Sep 2008 09:25:56 +0200 Subject: MTA Survey In-Reply-To: <1222326691.29270.10.camel@roswell.ausics.net> References: <1222326691.29270.10.camel@roswell.ausics.net> Message-ID: <48DB3D04.4050302@karnaugh.za.net> Noel Butler wrote: > Some of you may recall back in late 2006 we ran an international poll on > MTA's, where over a period of several months and 12 and half thousands > voters later, Sendmail was declared king, followed by Qmail, then Exim > then Postfix, Exchange and some lesser know immaterials ... Your survey has a gaping flaw I'm afraid. For example, 100 nameless people click on the Sendmail button because it came free with FreeBSD, versus those of us who have fleets numbering the thousands of Exim servers and he only gets to vote once. Oh dear... From nenolod at systeminplace.net Thu Sep 25 03:28:23 2008 From: nenolod at systeminplace.net (William Pitcock) Date: Thu, 25 Sep 2008 03:28:23 -0500 Subject: MTA Survey In-Reply-To: <48DB3D04.4050302@karnaugh.za.net> References: <1222326691.29270.10.camel@roswell.ausics.net> <48DB3D04.4050302@karnaugh.za.net> Message-ID: <1222331303.20200.1411.camel@petrie.sacredspiral.co.uk> Hi, On Thu, 2008-09-25 at 09:25 +0200, Colin Alston wrote: > Noel Butler wrote: > > Some of you may recall back in late 2006 we ran an international poll on > > MTA's, where over a period of several months and 12 and half thousands > > voters later, Sendmail was declared king, followed by Qmail, then Exim > > then Postfix, Exchange and some lesser know immaterials ... > > Your survey has a gaping flaw I'm afraid. For example, 100 nameless > people click on the Sendmail button because it came free with FreeBSD, > versus those of us who have fleets numbering the thousands of Exim > servers and he only gets to vote once. Oh dear... > Also, what about situations where there's multiple kinds of MTAs running in a network? William From michael.dillon at bt.com Thu Sep 25 04:26:41 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 25 Sep 2008 10:26:41 +0100 Subject: Atrivo/Intercage In-Reply-To: <6cd462c00809241908j6f858d42l68c6f54133b0dbd8@mail.gmail.com> Message-ID: > It could be argued (since _is_ the North American Network > Operators Group) that pushing this sort of criminal activity > _out_ of North America is a good First Step.... to be able to > better manage the situation. It could also be argued that pushing this activity into multiple legal jurisdictions just makes it darn near impossible for law enforcement to take any action. --Michael Dillon From rsk at gsp.org Thu Sep 25 06:12:07 2008 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 25 Sep 2008 07:12:07 -0400 Subject: the Intercage mess In-Reply-To: <1222312242.20200.1376.camel@petrie.sacredspiral.co.uk> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> <6cd462c00809241928t3cfe214fn93ed7f38688112f7@mail.gmail.com> <1222311156.20200.1364.camel@petrie.sacredspiral.co.uk> <6cd462c00809241958w103ae971ya5038af0aa88975b@mail.gmail.com> <1222312242.20200.1376.camel@petrie.sacredspiral.co.uk> Message-ID: <20080925111207.GA2611@gsp.org> On Wed, Sep 24, 2008 at 10:10:42PM -0500, William Pitcock wrote: > I said _new_ approach. I agree that it was overdue, but they are being > cooperative with the anti-abuse community, so I think it is appropriate > to give them an opportunity to deliver on their promise. We did that. In 2003. And the abuse continued, and got worse. We did that. In 2004. And the abuse continued, and got worse. We did that. In 2005. And the abuse continued, and got worse. And so on. I suggest at least making a perfunctory effort to acquaint yourself with the long, sordid history of Atrivo/Intercage, and its numerous prior (and utterly specious) claims of "cooperation" and "reform" before commenting further. ---Rsk From tme at multicasttech.com Thu Sep 25 07:27:35 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 25 Sep 2008 08:27:35 -0400 Subject: a vernier of civilization... In-Reply-To: <58B1BC8C-19D5-46A1-A313-9A3B04F8112C@netconsonance.com> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> <58B1BC8C-19D5-46A1-A313-9A3B04F8112C@netconsonance.com> Message-ID: <15F1D21B-2C0B-46B3-911E-8302B3606864@multicasttech.com> Note that, at least in the spacecraft world, a vernier is an attitude adjustment rocket engine. I am not sure if NANOG is set up to do an attitude adjustment on civilization... Regards Marshall On Sep 25, 2008, at 1:48 AM, Jo Rhett wrote: > On Sep 24, 2008, at 7:24 PM, Randy Bush wrote: >> this way lies lynch mobs >> shall we at least apply a vernier of civilization? > > > Randy, I would agree if anything less had ever been effective. > > If you have a better idea, please explain to the rest of us. > > -- Jo Rhett > Net Consonance : consonant endings by net philanthropy, open source > and other randomness > > > From smartens at att.com Thu Sep 25 07:55:07 2008 From: smartens at att.com (MARTENS, SUSAN, ATTOPS) Date: Thu, 25 Sep 2008 08:55:07 -0400 Subject: the NANOG mess In-Reply-To: <48DB075A.2030707@psg.com> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com><48DAF651.70608@psg.com> <6cd462c00809241928t3cfe214fn93ed7f38688112f7@mail.gmail.com> <1222311156.20200.1364.camel@petrie.sacredspiral.co.uk> <6cd462c00809241958w103ae971ya5038af0aa88975b@mail.gmail.com> <1222312242.20200.1376.camel@petrie.sacredspiral.co.uk> <6cd462c00809242014h3d5bd2bev61c8c710f0b4d40a@mail.gmail.com> <01759D50DC387C45A018FE1817CE27D751CBA4C0B5@CPExchange1.cpgreeley.com><6cd462c00809242030o2ec6550at2a90b9211ab4729f@mail.gmail.com> <48DB075A.2030707@psg.com> Message-ID: <60BFCABE00E72E45A8932F4C6AD8BA8ACAF81F@misout7msgusr7c.ugd.att.com> How about our Wed. night (Oct. 1)/your Thursday morning (Oct. 2) at 9? Would that work? Susan Martens AT&T Director Peering Planning 732-420-5095 smartens at att.com -----Original Message----- From: Randy Bush [mailto:randy at psg.com] Sent: Wednesday, September 24, 2008 11:37 PM To: Paul Ferguson Cc: nanog at nanog.org Subject: Re: the NANOG mess : * ^Return-Path:.*nanog-bounces * ^Subject:.*Intercage $TRASH enough already randy From smartens at att.com Thu Sep 25 07:56:41 2008 From: smartens at att.com (MARTENS, SUSAN, ATTOPS) Date: Thu, 25 Sep 2008 08:56:41 -0400 Subject: Recall: the NANOG mess Message-ID: <60BFCABE00E72E45A8932F4C6AD8BA8ACAF823@misout7msgusr7c.ugd.att.com> MARTENS, SUSAN, ATTOPS would like to recall the message, "the NANOG mess". From smartens at att.com Thu Sep 25 07:57:55 2008 From: smartens at att.com (MARTENS, SUSAN, ATTOPS) Date: Thu, 25 Sep 2008 08:57:55 -0400 Subject: the NANOG mess In-Reply-To: <60BFCABE00E72E45A8932F4C6AD8BA8ACAF81F@misout7msgusr7c.ugd.att.com> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com><48DAF651.70608@psg.com> <6cd462c00809241928t3cfe214fn93ed7f38688112f7@mail.gmail.com> <1222311156.20200.1364.camel@petrie.sacredspiral.co.uk> <6cd462c00809241958w103ae971ya5038af0aa88975b@mail.gmail.com> <1222312242.20200.1376.camel@petrie.sacredspiral.co.uk> <6cd462c00809242014h3d5bd2bev61c8c710f0b4d40a@mail.gmail.com> <01759D50DC387C45A018FE1817CE27D751CBA4C0B5@CPExchange1.cpgreeley.com><6cd462c00809242030o2ec6550at2a90b9211ab4729f@mail.gmail.com><48DB075A.2030707@psg.com> <60BFCABE00E72E45A8932F4C6AD8BA8ACAF81F@misout7msgusr7c.ugd.att.com> Message-ID: <60BFCABE00E72E45A8932F4C6AD8BA8ACAF825@misout7msgusr7c.ugd.att.com> Apologies to all -- I just fat-fingered an e-mail response. Susan Martens AT&T Director Peering Planning 732-420-5095 smartens at att.com -----Original Message----- From: MARTENS, SUSAN, ATTOPS Sent: Thursday, September 25, 2008 8:55 AM To: Randy Bush; Paul Ferguson Cc: nanog at nanog.org Subject: RE: the NANOG mess How about our Wed. night (Oct. 1)/your Thursday morning (Oct. 2) at 9? Would that work? Susan Martens AT&T Director Peering Planning 732-420-5095 smartens at att.com -----Original Message----- From: Randy Bush [mailto:randy at psg.com] Sent: Wednesday, September 24, 2008 11:37 PM To: Paul Ferguson Cc: nanog at nanog.org Subject: Re: the NANOG mess : * ^Return-Path:.*nanog-bounces * ^Subject:.*Intercage $TRASH enough already randy From vixie at isc.org Thu Sep 25 08:27:23 2008 From: vixie at isc.org (Paul Vixie) Date: Thu, 25 Sep 2008 13:27:23 +0000 Subject: Atrivo/Intercage In-Reply-To: (michael dillon's message of "Thu\, 25 Sep 2008 10\:26\:41 +0100") References: <6cd462c00809241908j6f858d42l68c6f54133b0dbd8@mail.gmail.com> Message-ID: michael.dillon at bt.com writes: > It could also be argued that pushing this activity into multiple > legal jurisdictions just makes it darn near impossible for law > enforcement to take any action. and you'd be able to measure this exactly how? instead of two prosecutions a year that lead to plea bargains or short stints in "camp fed", we'd have even fewer prosecutions with even lighter sentences? and that's a bad thing exactly why? let's push this stuff back into the nation-states who sponsor it and then use treaties to wall it off inside those places. -- Paul Vixie From paul.w.bennett at gmail.com Thu Sep 25 08:31:20 2008 From: paul.w.bennett at gmail.com (Paul Bennett) Date: Thu, 25 Sep 2008 09:31:20 -0400 Subject: obvious intent (Re: the Intercage mess) In-Reply-To: References: <1222311156.20200.1364.camel@petrie.sacredspiral.co.uk> Message-ID: <4ce04960809250631y329c557cj78de653fa7615290@mail.gmail.com> On 9/25/08, Paul Vixie wrote: > so, now begins the search for the line that mustn't be crossed. if they > have N spamming customer or M "captured" machines running C&C and they > disconnect such customers after P warnings or Q days, then will the > community still rise up in arms and if so will that still be enough > negativity to cause their (new?) provider to lose connectivity? if not, > then what about P-1 or Q+1 or M*2 or N/2? > > discovering the process by which N, M, P, and Q are discovered, will be > even uglier than everything we've seen on this topic to date. I work the at the abuse department of one of the big ISPs, and I have to note that finding effective values for those four varables is sticky business from the abuse preventers' side too. We get tens of thousands of abuse complaints every single day. Even filtering out the frequent-flyer abuse miscomplainers (certain ISPs seem to have no outbound filtering -- to cope with the very large number of times when their customers seem to confuse "Report Spam" with "Move to Trash", for instance), there's still a butt-load of data to be analysed and acted on, and only a finite number of monkeys with typewriters to churn through it. At best, it's a trans-global game of whack-a-mole, suspending orgs and consumers who have never heard the word "firewall", or at least have never learned router ACL config. Add to this the potential legal and/or press minefield of being accused of wiretapping, traffic-shaping, and other nefarious deeds, and we have to tread very gently indeed around certain abuse detection and prevention issues. In short, it's a big hairy beast, and it's even scarier if you take a closer-than-normal look. Paul (not an official spokesperson, nor a policy-maker, of any ISP or similar company) From jashton at esnet.com Thu Sep 25 08:42:55 2008 From: jashton at esnet.com (James Ashton) Date: Thu, 25 Sep 2008 09:42:55 -0400 Subject: the Intercage mess In-Reply-To: <1222311156.20200.1364.camel@petrie.sacredspiral.co.uk> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> <6cd462c00809241928t3cfe214fn93ed7f38688112f7@mail.gmail.com> <1222311156.20200.1364.camel@petrie.sacredspiral.co.uk> Message-ID: >No, but forcing them offline now that they are taking a new approach to >handling abuse is ridiculous. > >Intercage are reaching out to the anti-abuse community and yet some >people on NANOG keep interfering with the cleanup process. How do you >expect them to clean up their network and return to normal operations >(with considerably less abuse) if it keeps being disconnected? > >The shit isn't even there anymore. These kids have moved it elsewhere. >Intercage have learned their lesson, just leave them alone and let the >people who have *real* problems (e.g. me, Andrew Kirch of AHBL, >Spamhaus, Gadi, etc.) with Intercage deal with this. > >If anyone has any issue with Atrivo/Intercage that still needs >rectification: please contact me or Andrew Kirch offlist and we will >bring it to their attention. We have contact with these people, and they >are listening and taking action to clean up their network. > >If not, then please stop with this thread. It's not helpful, and it's >certaintly counter-productive. > >William William, This above email is a bit off. It sounds a bit like you feel that Nanog is your (Gadi/you/Andrew/Spamhaus) stick to force Intercage to fall in line. Not that they have been whacked with the stick you want the rest of us to leave them along so YOU can deal with it. But it is NOT your place to deal with it any more than it is mine. It is a community issue dealt with by the community and if the community (I.E. those who have killed intercage's connectivity) choose to keep it that way as opposed to taking the chance that this company, with a LONG history, will continue to spew unwanted traffic, well... That's not your call. It is not your place to tell someone else how to run their network and it is not your place to deal with the intercage issue on behalf of anyone else. James From michael.dillon at bt.com Thu Sep 25 09:20:22 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 25 Sep 2008 15:20:22 +0100 Subject: Wall it off, make it go away In-Reply-To: Message-ID: > let's push this stuff back into the nation-states who sponsor > it and then use treaties to wall it off inside those places. Let's not mince words. You want to wall off the Chinese and Russian Internets because you believe that the reason so much cybercrime originates there is for political reasons (state sponsorship) rather than economic ones. Have you ever visited these countries (Moscow and Beijing don't count) and seen how people live? There is a much larger economic incentive than you can imagine. Using the exchange rate figures from xe.com does not tell you how valuable an American dollar is in those countries. You need to spend enough time in the country to see how it costs to ride a bus, buy your lunch, etc. In fact, cybercrime originates abroad because the economic incentive is so great in those countries, and their level of technical education is high enough that they can actually build the distributed software systems that they need to drive the flow of hard cash. Fiddling with router configs, or mail server configs, does not change this. In fact, the economic incentive for a NANOG reader to block the bad stuff is probably a lot lower than for the foreign bad guy to evade your blocks. He will just route around your efforts. Economic and legal problems should be fixed in the economic and legal system, not in network operations. People on this list would do more good by supporting legal and economic efforts to fix the problem than by tweaking their routers. Or by simply ignoring the problem because it is a lot easier for law enforcement to hit a standing target. In any case, I don't believe that nation states sponsor cybercrime. Bad guys are found in every country and they will always act for their own benefit regardless of what laws or treaties may be put in place. Over the past 15 years, it has been shown that network vigilantism does not work. If anything, this just makes cybercriminals stronger by forcing them to evolve their systems, and by weeding out the less intelligent ones. --Michael Dillon From LarrySheldon at cox.net Thu Sep 25 09:21:56 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Thu, 25 Sep 2008 09:21:56 -0500 Subject: the Intercage mess In-Reply-To: <20080925111207.GA2611@gsp.org> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> <6cd462c00809241928t3cfe214fn93ed7f38688112f7@mail.gmail.com> <1222311156.20200.1364.camel@petrie.sacredspiral.co.uk> <6cd462c00809241958w103ae971ya5038af0aa88975b@mail.gmail.com> <1222312242.20200.1376.camel@petrie.sacredspiral.co.uk> <20080925111207.GA2611@gsp.org> Message-ID: <48DB9E84.5050207@cox.net> Rich Kulawiec wrote: > On Wed, Sep 24, 2008 at 10:10:42PM -0500, William Pitcock wrote: >> I said _new_ approach. I agree that it was overdue, but they are being >> cooperative with the anti-abuse community, so I think it is appropriate >> to give them an opportunity to deliver on their promise. > > We did that. In 2003. And the abuse continued, and got worse. > > We did that. In 2004. And the abuse continued, and got worse. > > We did that. In 2005. And the abuse continued, and got worse. > > And so on. > > I suggest at least making a perfunctory effort to acquaint yourself with > the long, sordid history of Atrivo/Intercage, and its numerous prior > (and utterly specious) claims of "cooperation" and "reform" before > commenting further. What was the deal about doing the same thing over and over and over and over, each time expecting the outcome to be different? From LarrySheldon at cox.net Thu Sep 25 09:24:00 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Thu, 25 Sep 2008 09:24:00 -0500 Subject: Recall: the NANOG mess In-Reply-To: <60BFCABE00E72E45A8932F4C6AD8BA8ACAF823@misout7msgusr7c.ugd.att.com> References: <60BFCABE00E72E45A8932F4C6AD8BA8ACAF823@misout7msgusr7c.ugd.att.com> Message-ID: <48DB9F00.1020406@cox.net> MARTENS, SUSAN, ATTOPS wrote: > MARTENS, SUSAN, ATTOPS would like to recall the message, "the NANOG mess". Ahhhh....The Brave New World. Technology, in spite of what the salesperson told you, will not allow you to unring a bell. From tomb at byrneit.net Thu Sep 25 09:50:46 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Thu, 25 Sep 2008 07:50:46 -0700 Subject: MTA Survey In-Reply-To: <1222331303.20200.1411.camel@petrie.sacredspiral.co.uk> References: <1222326691.29270.10.camel@roswell.ausics.net><48DB3D04.4050302@karnaugh.za.net> <1222331303.20200.1411.camel@petrie.sacredspiral.co.uk> Message-ID: <70D072392E56884193E3D2DE09C097A9F5FB@pascal.zaphodb.org> Or the highly likely scenario that the primary gateway accessible to the survey tool is some load balanced SPAM filtering cluster, and not the MTA in use as final delivery. > -----Original Message----- > From: William Pitcock [mailto:nenolod at systeminplace.net] > Sent: Thursday, September 25, 2008 1:28 AM > To: Colin Alston > Cc: nanog at nanog.org > Subject: Re: MTA Survey > > Hi, > > On Thu, 2008-09-25 at 09:25 +0200, Colin Alston wrote: > > Noel Butler wrote: > > > Some of you may recall back in late 2006 we ran an international > > > poll on MTA's, where over a period of several months and > 12 and half > > > thousands voters later, Sendmail was declared king, followed by > > > Qmail, then Exim then Postfix, Exchange and some lesser > know immaterials ... > > > > Your survey has a gaping flaw I'm afraid. For example, 100 nameless > > people click on the Sendmail button because it came free > with FreeBSD, > > versus those of us who have fleets numbering the thousands of Exim > > servers and he only gets to vote once. Oh dear... > > > > Also, what about situations where there's multiple kinds of > MTAs running in a network? > > William > > > From tomb at byrneit.net Thu Sep 25 10:12:05 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Thu, 25 Sep 2008 08:12:05 -0700 Subject: a vernier of civilization... In-Reply-To: <15F1D21B-2C0B-46B3-911E-8302B3606864@multicasttech.com> References: <20080924133743.944847809@relayer.avian.org><48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com><58B1BC8C-19D5-46A1-A313-9A3B04F8112C@netconsonance.com> <15F1D21B-2C0B-46B3-911E-8302B3606864@multicasttech.com> Message-ID: <70D072392E56884193E3D2DE09C097A9F5FC@pascal.zaphodb.org> Am I the only one who read that as intending to be "Veneer", a thin covering to make it look like, even if the subsurface reality is the raw randomness of particle board? I would note that; while it seems like the OP wanted to say that we were to make the process of running outlaws out of town (which is the equivalent of what we're doing here) at least a bit civilized; in the context outside of decoration, a veneer means "superficial or deceptively attractive appearance", IE: for looks only, not changing the inherent character of the thing it's meant to cover up. I guess, it we want better PR, a veneer of judges, bailiffs, and lawyers can't hurt us. We should still let our well clad lawmen unload with all barrels on the louts that have been terrorizing the neighborhood. > -----Original Message----- > From: Marshall Eubanks [mailto:tme at multicasttech.com] > Sent: Thursday, September 25, 2008 5:28 AM > To: Jo Rhett > Cc: Nanog list > Subject: Re: a vernier of civilization... > > Note that, at least in the spacecraft world, a vernier is an > attitude adjustment rocket engine. > > I am not sure if NANOG is set up to do an attitude adjustment > on civilization... > > Regards > Marshall > > On Sep 25, 2008, at 1:48 AM, Jo Rhett wrote: > > > On Sep 24, 2008, at 7:24 PM, Randy Bush wrote: > >> this way lies lynch mobs > >> shall we at least apply a vernier of civilization? > > > > > > Randy, I would agree if anything less had ever been effective. > > > > If you have a better idea, please explain to the rest of us. > > > > -- Jo Rhett > > Net Consonance : consonant endings by net philanthropy, open source > > and other randomness > > > > > > > > > From karnaugh at karnaugh.za.net Thu Sep 25 09:57:52 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Thu, 25 Sep 2008 16:57:52 +0200 Subject: MTA Survey In-Reply-To: <70D072392E56884193E3D2DE09C097A9F5FB@pascal.zaphodb.org> References: <1222326691.29270.10.camel@roswell.ausics.net><48DB3D04.4050302@karnaugh.za.net> <1222331303.20200.1411.camel@petrie.sacredspiral.co.uk> <70D072392E56884193E3D2DE09C097A9F5FB@pascal.zaphodb.org> Message-ID: <48DBA6F0.2090805@karnaugh.za.net> Tomas L. Byrnes wrote: > Or the highly likely scenario that the primary gateway accessible to the > survey tool is some load balanced SPAM filtering cluster, and not the > MTA in use as final delivery. > Good point, real MTA in front of Excange is extremely common.. From randy at psg.com Thu Sep 25 09:59:36 2008 From: randy at psg.com (Randy Bush) Date: Thu, 25 Sep 2008 23:59:36 +0900 Subject: a vernier of civilization... In-Reply-To: <15F1D21B-2C0B-46B3-911E-8302B3606864@multicasttech.com> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> <58B1BC8C-19D5-46A1-A313-9A3B04F8112C@netconsonance.com> <15F1D21B-2C0B-46B3-911E-8302B3606864@multicasttech.com> Message-ID: <48DBA758.3030703@psg.com> > I am not sure if NANOG is set up to do an attitude adjustment on > civilization... it keeps trying. thunderbleep scorned verneer, so i tried ier and it worked. randy From Martin.Hannigan at verneglobal.com Thu Sep 25 10:34:20 2008 From: Martin.Hannigan at verneglobal.com (Martin Hannigan) Date: Thu, 25 Sep 2008 15:34:20 -0000 Subject: {** Spam **} ** {Spam} ** Re: YAY! Re: Atrivo/Intercage: NO Upstream depeer In-Reply-To: <648989.85024.qm@web45013.mail.sp1.yahoo.com> References: <648989.85024.qm@web45013.mail.sp1.yahoo.com> Message-ID: Anyone have a measurement so that we can see the impact and give Intercage some credit and set a baseline, regardless of how they got there, and move on? -M< From tme at multicasttech.com Thu Sep 25 10:39:06 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 25 Sep 2008 11:39:06 -0400 Subject: a vernier of civilization... In-Reply-To: <48DBA758.3030703@psg.com> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> <58B1BC8C-19D5-46A1-A313-9A3B04F8112C@netconsonance.com> <15F1D21B-2C0B-46B3-911E-8302B3606864@multicasttech.com> <48DBA758.3030703@psg.com> Message-ID: Dear Randy; On Sep 25, 2008, at 10:59 AM, Randy Bush wrote: >> I am not sure if NANOG is set up to do an attitude adjustment on >> civilization... > > it keeps trying. > > > thunderbleep scorned verneer, so i tried ier and it worked. > Yes, I knew this was a typo, but I figured a little levity couldn't hurt this depressing thread. Hope all is well. Regards Marshall > randy From LarrySheldon at cox.net Thu Sep 25 10:42:18 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Thu, 25 Sep 2008 10:42:18 -0500 Subject: a vernier of civilization... In-Reply-To: References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> <58B1BC8C-19D5-46A1-A313-9A3B04F8112C@netconsonance.com> <15F1D21B-2C0B-46B3-911E-8302B3606864@multicasttech.com> <48DBA758.3030703@psg.com> Message-ID: <48DBB15A.9080005@cox.net> Marshall Eubanks wrote: > Dear Randy; > On Sep 25, 2008, at 10:59 AM, Randy Bush wrote: >>> I am not sure if NANOG is set up to do an attitude adjustment on >>> civilization... >> >> it keeps trying. >> >> thunderbleep scorned verneer, so i tried ier and it worked. >> > > Yes, I knew this was a typo, but I figured a little levity couldn't hurt > this depressing thread. The thread is more about plating a turd. From David_Hankins at isc.org Thu Sep 25 10:42:22 2008 From: David_Hankins at isc.org (David W. Hankins) Date: Thu, 25 Sep 2008 08:42:22 -0700 Subject: the Intercage mess In-Reply-To: <48DAF651.70608@psg.com> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> Message-ID: <20080925154222.GA5514@isc.org> On Thu, Sep 25, 2008 at 11:24:17AM +0900, Randy Bush wrote: > John Bambenek wrote: > > When there is no law to speak of all that is left is tribal justice. > > this way lies lynch mobs Maybe mobs, but not (Charles) Lynch mobs. No one wants to deprive anyone of life or limb. > shall we at least apply a veneer of civilization? I think the current state of the art in civilized, peaceful, extralegal negotiation of reasonable behaviour expected of businessmen and their peers is a form of social ostracism given its name in 1880 when the Irish Land League bade everyone in Mayo county, Ireland not to engage economically or otherwise with Captain Charles Boycott...a land owner who had set his rent very high, and was evicting anyone who deigned to complain of it (fully within his legal authority, but outside the realms of what the people saw as reasonable). If anyone can think of better, we'll have to call it "Intercaging". -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ -- 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: 194 bytes Desc: not available URL: From streiner at cluebyfour.org Thu Sep 25 11:37:40 2008 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 25 Sep 2008 12:37:40 -0400 (EDT) Subject: rackmount managed PDUs Message-ID: As much as I hate to tear people away from the Intercage/Atrivo debacle and semi-tangential rants, I'll take one for the team and do it :) I have an opportunity coming up to rebuild an existing machine room space to an extent. It's not a total gut-and-refit, but I'll at least get to put in some new infrastructure. That said, I'd be interested in hearing about peoples' experiences with various rackmountable managed PDUs. I have some Tripp Lite PDUMH30NETs that work well and are reasonably priced, but they have a few quirks (no RS-232 console port, web interface seems to be a little shaky with Firefox, etc) that would become more annoying when scaled up to several rows of new rack footprints. I'm also open to using managed vertically mounted PDUs. The plan is for each footprint to have "A" and B" feeds, so two PDUMH30NETs would take up 4U per footprint, which is a bit much... I don't need to worry about distributing DC power - just AC. This site will be lights-out most of the time, so robust remote management capabilities are a must. Any thoughts/insight are greatly appreciated. jms From justin at justinshore.com Thu Sep 25 11:39:44 2008 From: justin at justinshore.com (Justin Shore) Date: Thu, 25 Sep 2008 11:39:44 -0500 Subject: Where to move the Intercage/Atrivo discussion (was: the Intercage mess) In-Reply-To: <20080925154222.GA5514@isc.org> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> <20080925154222.GA5514@isc.org> Message-ID: <48DBBED0.4020507@justinshore.com> David W. Hankins wrote: > I think the current state of the art in civilized, peaceful, > extralegal negotiation of reasonable behaviour expected of businessmen > and their peers is a form of social ostracism given its name in 1880 > when the Irish Land League bade everyone in Mayo county, Ireland not > to engage economically or otherwise with Captain Charles Boycott...a > land owner who had set his rent very high, and was evicting anyone who > deigned to complain of it (fully within his legal authority, but > outside the realms of what the people saw as reasonable). > > If anyone can think of better, we'll have to call it "Intercaging". Since the usefulness of this thread to NANOG is becoming less and less as the thread wears on, where would the NANOG community suggest that it be moved to? What are the good SP operational security mailing lists? What groups or forums would one find threads like this? The NANOG ISP security BOF group? I would like to do a much better job of keeping up on things of this nature. I already spend a great deal of time on it but I know that I'm missing a plethora of other security issues. What group would be interested in knowing that whois.estdomains.com (83.171.76.99) is now being hosted by as31353 via as8997 (didn't we have a small problem with 8997 the other day?)? I'd love to find the good lists and forums for this type of discussion, preferably with a SP slant. Perhaps that info will help move the discussion to more appropriate places. Thanks Justin From trelane at trelane.net Thu Sep 25 11:41:06 2008 From: trelane at trelane.net (Andrew D Kirch) Date: Thu, 25 Sep 2008 12:41:06 -0400 Subject: rackmount managed PDUs In-Reply-To: References: Message-ID: <48DBBF22.6070509@trelane.net> http://www.webpowerswitch.com/ I've used these quite a bit. Depending on the model you can get per port or per zone power management, and it sends alerts if it's not in the state it's supposed to be, and some of them can auto kickover things like routers if they suddenly cant route (might be dangerous, I don't use this one except at the CPE) Andrew Justin M. Streiner wrote: > As much as I hate to tear people away from the Intercage/Atrivo > debacle and semi-tangential rants, I'll take one for the team and do > it :) > > I have an opportunity coming up to rebuild an existing machine room > space to an extent. It's not a total gut-and-refit, but I'll at least > get to put in some new infrastructure. That said, I'd be interested > in hearing about peoples' experiences with various rackmountable > managed PDUs. > > I have some Tripp Lite PDUMH30NETs that work well and are reasonably > priced, but they have a few quirks (no RS-232 console port, web > interface seems to be a little shaky with Firefox, etc) that would > become more annoying when scaled up to several rows of new rack > footprints. I'm also open to using managed vertically mounted PDUs. > The plan is for each footprint to have "A" and B" feeds, so two > PDUMH30NETs would take up 4U per footprint, which is a bit much... > > I don't need to worry about distributing DC power - just AC. > > This site will be lights-out most of the time, so robust remote > management capabilities are a must. > > Any thoughts/insight are greatly appreciated. > > jms > From mjkelly at gmail.com Thu Sep 25 11:41:31 2008 From: mjkelly at gmail.com (Matt Kelly) Date: Thu, 25 Sep 2008 12:41:31 -0400 Subject: rackmount managed PDUs In-Reply-To: References: Message-ID: <677739F8-5263-4F0B-9245-6C76A036E5C5@gmail.com> APC makes "0U" units for different types of electric hand offs. AP7932 is a unit we've used with great success in the past. APC's SNMP access is great as well since it can be integrated with just about any kind of system. --Matt On Sep 25, 2008, at 12:37 PM, Justin M. Streiner wrote: > As much as I hate to tear people away from the Intercage/Atrivo > debacle and semi-tangential rants, I'll take one for the team and do > it :) > > I have an opportunity coming up to rebuild an existing machine room > space to an extent. It's not a total gut-and-refit, but I'll at > least get to put in some new infrastructure. That said, I'd be > interested in hearing about peoples' experiences with various > rackmountable managed PDUs. > > I have some Tripp Lite PDUMH30NETs that work well and are reasonably > priced, but they have a few quirks (no RS-232 console port, web > interface seems to be a little shaky with Firefox, etc) that would > become more annoying when scaled up to several rows of new rack > footprints. I'm also open to using managed vertically mounted > PDUs. The plan is for each footprint to have "A" and B" feeds, so > two PDUMH30NETs would take up 4U per footprint, which is a bit much... > > I don't need to worry about distributing DC power - just AC. > > This site will be lights-out most of the time, so robust remote > management capabilities are a must. > > Any thoughts/insight are greatly appreciated. > > jms > From pstewart at nexicomgroup.net Thu Sep 25 11:45:53 2008 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Thu, 25 Sep 2008 12:45:53 -0400 Subject: rackmount managed PDUs In-Reply-To: <48DBBF22.6070509@trelane.net> References: <48DBBF22.6070509@trelane.net> Message-ID: <89D27DE3375BB6428DDCC2927489826A019E3410@nexus.nexicomgroup.net> We have a lot of APC managed power bars (zero U vertical, and 19" 1U rackmount) and they work great. We SNMP manage them and access them via web - they just work, and work well for our needs. Tripplite we've had issues with over time, especially their UPS units (SNMP sucks on them). Hope this helps a bit.. Take care, Paul -----Original Message----- From: Andrew D Kirch [mailto:trelane at trelane.net] Sent: Thursday, September 25, 2008 12:41 PM Cc: nanog at nanog.org Subject: Re: rackmount managed PDUs http://www.webpowerswitch.com/ I've used these quite a bit. Depending on the model you can get per port or per zone power management, and it sends alerts if it's not in the state it's supposed to be, and some of them can auto kickover things like routers if they suddenly cant route (might be dangerous, I don't use this one except at the CPE) Andrew Justin M. Streiner wrote: > As much as I hate to tear people away from the Intercage/Atrivo > debacle and semi-tangential rants, I'll take one for the team and do > it :) > > I have an opportunity coming up to rebuild an existing machine room > space to an extent. It's not a total gut-and-refit, but I'll at least > get to put in some new infrastructure. That said, I'd be interested > in hearing about peoples' experiences with various rackmountable > managed PDUs. > > I have some Tripp Lite PDUMH30NETs that work well and are reasonably > priced, but they have a few quirks (no RS-232 console port, web > interface seems to be a little shaky with Firefox, etc) that would > become more annoying when scaled up to several rows of new rack > footprints. I'm also open to using managed vertically mounted PDUs. > The plan is for each footprint to have "A" and B" feeds, so two > PDUMH30NETs would take up 4U per footprint, which is a bit much... > > I don't need to worry about distributing DC power - just AC. > > This site will be lights-out most of the time, so robust remote > management capabilities are a must. > > Any thoughts/insight are greatly appreciated. > > jms > ---------------------------------------------------------------------------- "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 LarrySheldon at cox.net Thu Sep 25 11:46:33 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Thu, 25 Sep 2008 11:46:33 -0500 Subject: Where to move the Intercage/Atrivo discussion In-Reply-To: <48DBBED0.4020507@justinshore.com> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> <20080925154222.GA5514@isc.org> <48DBBED0.4020507@justinshore.com> Message-ID: <48DBC069.5000405@cox.net> Justin Shore wrote: > Since the usefulness of this thread to NANOG is becoming less and less > as the thread wears on, where would the NANOG community suggest that it > be moved to? Kind of a custom-fit for NANAE, isn't it? From nuno.vieira at nfsi.pt Thu Sep 25 11:45:08 2008 From: nuno.vieira at nfsi.pt (Nuno Vieira - nfsi telecom) Date: Thu, 25 Sep 2008 17:45:08 +0100 (WEST) Subject: rackmount managed PDUs In-Reply-To: Message-ID: <2133595822.49561222361108769.JavaMail.root@zimbra.nfsi.pt> We use APANET powerswitches, and we are quite happy with them. 24 ports units, around 600 EUR per unit. www.apanet.pl --- Nuno Vieira nfsi telecom, lda. nuno.vieira at nfsi.pt Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 http://www.nfsi.pt/ ----- "Justin M. Streiner" wrote: > As much as I hate to tear people away from the Intercage/Atrivo > debacle > and semi-tangential rants, I'll take one for the team and do it :) > > I have an opportunity coming up to rebuild an existing machine room > space > to an extent. It's not a total gut-and-refit, but I'll at least get > to > put in some new infrastructure. That said, I'd be interested in > hearing > about peoples' experiences with various rackmountable managed PDUs. > > I have some Tripp Lite PDUMH30NETs that work well and are reasonably > priced, but they have a few quirks (no RS-232 console port, web > interface > seems to be a little shaky with Firefox, etc) that would become more > annoying when scaled up to several rows of new rack footprints. I'm > also > open to using managed vertically mounted PDUs. The plan is for each > footprint to have "A" and B" feeds, so two PDUMH30NETs would take up > 4U > per footprint, which is a bit much... > > I don't need to worry about distributing DC power - just AC. > > This site will be lights-out most of the time, so robust remote > management > capabilities are a must. > > Any thoughts/insight are greatly appreciated. > > jms From Valdis.Kletnieks at vt.edu Thu Sep 25 11:53:14 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 25 Sep 2008 12:53:14 -0400 Subject: Where to move the Intercage/Atrivo discussion (was: the Intercage mess) In-Reply-To: Your message of "Thu, 25 Sep 2008 11:39:44 CDT." <48DBBED0.4020507@justinshore.com> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> <20080925154222.GA5514@isc.org> <48DBBED0.4020507@justinshore.com> Message-ID: <26006.1222361594@turing-police.cc.vt.edu> On Thu, 25 Sep 2008 11:39:44 CDT, Justin Shore said: > group would be interested in knowing that whois.estdomains.com > (83.171.76.99) is now being hosted by as31353 via as8997 (didn't we have Well, that didn't take long. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From nuno.vieira at nfsi.pt Thu Sep 25 11:51:51 2008 From: nuno.vieira at nfsi.pt (Nuno Vieira - nfsi telecom) Date: Thu, 25 Sep 2008 17:51:51 +0100 (WEST) Subject: rackmount managed PDUs In-Reply-To: <2133595822.49561222361108769.JavaMail.root@zimbra.nfsi.pt> Message-ID: <1756523495.49641222361511966.JavaMail.root@zimbra.nfsi.pt> the right url is http://www.apanet.pl/en/produkty_ippc24.html cheers, --nvieira ----- "Nuno Vieira - nfsi telecom" wrote: > We use APANET powerswitches, and we are quite happy with them. > > 24 ports units, around 600 EUR per unit. > > www.apanet.pl > --- > Nuno Vieira > nfsi telecom, lda. > > nuno.vieira at nfsi.pt > Tel. (+351) 21 949 2300 - Fax (+351) 21 949 2301 > http://www.nfsi.pt/ > > > > ----- "Justin M. Streiner" wrote: > > > As much as I hate to tear people away from the Intercage/Atrivo > > debacle > > and semi-tangential rants, I'll take one for the team and do it :) > > > > I have an opportunity coming up to rebuild an existing machine room > > space > > to an extent. It's not a total gut-and-refit, but I'll at least > get > > to > > put in some new infrastructure. That said, I'd be interested in > > hearing > > about peoples' experiences with various rackmountable managed PDUs. > > > > I have some Tripp Lite PDUMH30NETs that work well and are reasonably > > > priced, but they have a few quirks (no RS-232 console port, web > > interface > > seems to be a little shaky with Firefox, etc) that would become more > > > annoying when scaled up to several rows of new rack footprints. > I'm > > also > > open to using managed vertically mounted PDUs. The plan is for each > > > footprint to have "A" and B" feeds, so two PDUMH30NETs would take > up > > 4U > > per footprint, which is a bit much... > > > > I don't need to worry about distributing DC power - just AC. > > > > This site will be lights-out most of the time, so robust remote > > management > > capabilities are a must. > > > > Any thoughts/insight are greatly appreciated. > > > > jms From justin at justinshore.com Thu Sep 25 11:56:45 2008 From: justin at justinshore.com (Justin Shore) Date: Thu, 25 Sep 2008 11:56:45 -0500 Subject: rackmount managed PDUs In-Reply-To: References: Message-ID: <48DBC2CD.5060100@justinshore.com> Justin M. Streiner wrote: > I have some Tripp Lite PDUMH30NETs that work well and are reasonably > priced, but they have a few quirks (no RS-232 console port, web > interface seems to be a little shaky with Firefox, etc) that would > become more annoying when scaled up to several rows of new rack > footprints. I'm also open to using managed vertically mounted PDUs. > The plan is for each footprint to have "A" and B" feeds, so two > PDUMH30NETs would take up 4U per footprint, which is a bit much... One thing to be aware of with the vertical PDUs is where they get mounted. A number of vertical Emerson PDUs were purchased for our DC. However only one of the Liebert cabinets was purchased with the 6" extension on the rear. The PDUs mount on each side of the cabinet door frame with the receptacles facing the opposing PDU. Ie, both PDUs face inward towards each other, not towards the front or rear of the cabinet. They stick out about 2" plus the power cords stick out at least another 2", more depending on how hard you fight to force the power cables into bundles and wire-tie them off to the frame. The rails of the servers barely clear the PDUs. The cabling on the back of the servers is made all the harder by the bundle of power cables in the way. It's a difficult physical problem to work around. The 6" cabinet extension would have allowed the PDUs to be moved further from the servers and would have allowed for a little more robust form of wire management for the power cables. Now in our CO we bought a cabinet thats 28" wide (Cooper/B-Line). There's enough space on each side for 4" of vertical wire management. Vertical PDUs would be viable in that scenario. Just something to consider. Justin PS==> The Emerson PDUs are supposed to be manageable, though I've never seen the GUI. From sil at infiltrated.net Thu Sep 25 12:06:51 2008 From: sil at infiltrated.net (J. Oquendo) Date: Thu, 25 Sep 2008 12:06:51 -0500 Subject: Where to move the Intercage/Atrivo discussion (was: the Intercage mess) In-Reply-To: <48DBBED0.4020507@justinshore.com> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> <20080925154222.GA5514@isc.org> <48DBBED0.4020507@justinshore.com> Message-ID: <20080925170651.GB31947@infiltrated.net> On Thu, 25 Sep 2008, Justin Shore wrote: > David W. Hankins wrote: > >I think the current state of the art in civilized, peaceful, > >extralegal negotiation of reasonable behaviour expected of businessmen > >and their peers is a form of social ostracism given its name in 1880 > >when the Irish Land League bade everyone in Mayo county, Ireland not > >to engage economically or otherwise with Captain Charles Boycott...a > >land owner who had set his rent very high, and was evicting anyone who > >deigned to complain of it (fully within his legal authority, but > >outside the realms of what the people saw as reasonable). > > > >If anyone can think of better, we'll have to call it "Intercaging". > > Since the usefulness of this thread to NANOG is becoming less and less > as the thread wears on, where would the NANOG community suggest that it > be moved to? What are the good SP operational security mailing lists? > What groups or forums would one find threads like this? The NANOG ISP > security BOF group? I would like to do a much better job of keeping up > on things of this nature. I already spend a great deal of time on it > but I know that I'm missing a plethora of other security issues. What > group would be interested in knowing that whois.estdomains.com > (83.171.76.99) is now being hosted by as31353 via as8997 (didn't we have > a small problem with 8997 the other day?)? I'd love to find the good > lists and forums for this type of discussion, preferably with a SP > slant. Perhaps that info will help move the discussion to more > appropriate places. > > Thanks > Justin > For the duration of this thread and others like it, I have to step back and wonder why is it when operational issues that some don't like to talk about come up, why they're often shifted to some form of offtopic status: "Well it doesn't do me any good therefore we should move it off the list!" This is and was relevant to issues such as botnets which (drum roll) affect network operations to even Denial of Service attacks which I can recall the urge to move to offtopic land going back to pre Y2K. What are the terms? Status Quo Bias, Selective Recall, Groupthink, False Consensus, Herding Instinct. Randy makes a good point as do others involved in the operations decisions but the decision should be based on realistic input from everyone, not just those who conform to someone's specific liking. I'm no judge and jury to implicity cut off someone's connectivity nor is anyone else and this entire situation is akin to a lynching like the verbiage or not. While I agree that rogue providers and hosts need to be dealt with, the issue needs to be addressed by everyone in order to show there was accuracy and fairness not just the "good old boy" networked approach. Not solely using the Groupthink approach. Perhaps this would have been better dealt with if there was a mechanism in place to have all vote together or perhaps a committee need be created where these issues can be resolved diplomatically and efficiently which stays far and clear of the Not In My Back Yard attitude. Business deals are business deals like them or not. If you made a strategic decision based on what you thought was appropriate at the time, how would YOU like it if someone came to YOUR backyard protesting "Oh no you don't!". "A man's judgement cannot be better than the information on which he has based it" Arthur Sulzberger Perhaps whatever company decided whatever decision they made based on the best information available to them at the time. Is it fair for you to cut off their arm without getting their end of the view before cutting off their arm. Then complaining its not in your best interest to hear their case. I hope for someone's sake you're never a juror for them. I'd always had this impression that NANOG was the de-facto place where experts would get together to make strategic decisions, set forth best practices, provide in-depth information on policies, etc., with regards to Internet operations. It's beginning to look like the description of the intelligence agencies skewing matters to their own likings in order to go to war. In order to justify their own agendas. Whether or not the agenda has meat and substance is not even being weighed I see nothing more than confirmation bias, selective recall, and the list goes on, but nowhere do I see anything other than a witchhunt right now. Place yourself in a situation like this and ask what would you like to have some body of (so called) experts do. Would you enjoy it if others ran around trying to hush any naysayer that didn't conform to your views. Would it be fair, would it truly be diplomatic. Maybe some need to take a good look at this and create a solution for future potential problems. Perhaps a rotating board of decision makers who would unbiasedly take a good look at a situation and offer a variety of solutions in which those solutions would need to be voted in (for lack of better terms) by a vast majority without that vast majority whining: "Oh shut up if you're not going to see things my way!" then siding with friends and colleagues or peers out of pressure. My unwanted two cents for the year. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, CNDA, CHFI, OSCP "A good district attorney can indict a ham sandwich if he wants to ... The accusations harm as much as the convictions ... they're obviously harmful or it wouldn't be news.." - John Carter wget -qO - www.infiltrated.net/sig|perl http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3AC173DB From streiner at cluebyfour.org Thu Sep 25 12:24:48 2008 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 25 Sep 2008 13:24:48 -0400 (EDT) Subject: rackmount managed PDUs In-Reply-To: <48DBC2CD.5060100@justinshore.com> References: <48DBC2CD.5060100@justinshore.com> Message-ID: On Thu, 25 Sep 2008, Justin Shore wrote: > One thing to be aware of with the vertical PDUs is where they get mounted. Good point. The cabinets we'd be using have 4" stand-offs between the rails and the cabinet frame, for wire management and they're fairly deep as well. Even at that, some servers seem to have obscenely deep foorprints - Dell PowerEdge 2850s come to mind :) I also have to wrestle with the wire management a bit, since some boxes have their network ports on the front and some have them on the back... jms From tme at multicasttech.com Thu Sep 25 12:32:25 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 25 Sep 2008 13:32:25 -0400 Subject: rackmount managed PDUs In-Reply-To: <89D27DE3375BB6428DDCC2927489826A019E3410@nexus.nexicomgroup.net> References: <48DBBF22.6070509@trelane.net> <89D27DE3375BB6428DDCC2927489826A019E3410@nexus.nexicomgroup.net> Message-ID: On Sep 25, 2008, at 12:45 PM, Paul Stewart wrote: > We have a lot of APC managed power bars (zero U vertical, and 19" 1U > rackmount) and they work great. We SNMP manage them and access them > via > web - they just work, and work well for our needs. Tripplite we've > had > issues with over time, especially their UPS units (SNMP sucks on > them). > I agree with this - we use APCs and the remote access is very useful. Note that 20 Amp and below units use standard 110 Volts and you can just plug them in, but the 40 Amp units (and I would presume above) require 3 phase 220 volt power, and that generally requires a licensed electrician for installation. Regards Marshall > Hope this helps a bit.. > > Take care, > > Paul > > > -----Original Message----- > From: Andrew D Kirch [mailto:trelane at trelane.net] > Sent: Thursday, September 25, 2008 12:41 PM > Cc: nanog at nanog.org > Subject: Re: rackmount managed PDUs > > http://www.webpowerswitch.com/ I've used these quite a bit. > Depending > on the model you can get per port or per zone power management, and it > sends alerts if it's not in the state it's supposed to be, and some of > them can auto kickover things like routers if they suddenly cant route > (might be dangerous, I don't use this one except at the CPE) > > Andrew > > Justin M. Streiner wrote: >> As much as I hate to tear people away from the Intercage/Atrivo >> debacle and semi-tangential rants, I'll take one for the team and do >> it :) >> >> I have an opportunity coming up to rebuild an existing machine room >> space to an extent. It's not a total gut-and-refit, but I'll at >> least > >> get to put in some new infrastructure. That said, I'd be interested >> in hearing about peoples' experiences with various rackmountable >> managed PDUs. >> >> I have some Tripp Lite PDUMH30NETs that work well and are reasonably >> priced, but they have a few quirks (no RS-232 console port, web >> interface seems to be a little shaky with Firefox, etc) that would >> become more annoying when scaled up to several rows of new rack >> footprints. I'm also open to using managed vertically mounted PDUs. >> The plan is for each footprint to have "A" and B" feeds, so two >> PDUMH30NETs would take up 4U per footprint, which is a bit much... >> >> I don't need to worry about distributing DC power - just AC. >> >> This site will be lights-out most of the time, so robust remote >> management capabilities are a must. >> >> Any thoughts/insight are greatly appreciated. >> >> jms >> > > > > > > > ---------------------------------------------------------------------------- > > "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 bmanning at vacation.karoshi.com Thu Sep 25 12:37:15 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 25 Sep 2008 17:37:15 +0000 Subject: breadcrumbs and collusion In-Reply-To: <20080925170651.GB31947@infiltrated.net> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> <20080925154222.GA5514@isc.org> <48DBBED0.4020507@justinshore.com> <20080925170651.GB31947@infiltrated.net> Message-ID: <20080925173715.GA16314@vacation.karoshi.com.> NANOG makes a fine archive of discoverable material in a court case intending to show collusion to drive folks out of business. One presumes that each ISP here has some form of AUP and rules on self-preservation roughly along the lines of "if there is material impact to my network or my customers, I can do whatever it takes to mitigate the traffic/intrusion". One does not need to collaberate with others before enforcing your own AUP. --bill From duane.waddle at gmail.com Thu Sep 25 12:40:49 2008 From: duane.waddle at gmail.com (Duane Waddle) Date: Thu, 25 Sep 2008 12:40:49 -0500 Subject: rackmount managed PDUs In-Reply-To: <48DBC2CD.5060100@justinshore.com> References: <48DBC2CD.5060100@justinshore.com> Message-ID: <80e7195b0809251040we535233q95ae9fc09815ea9b@mail.gmail.com> On Thu, Sep 25, 2008 at 11:56 AM, Justin Shore wrote: > > Justin M. Streiner wrote: > > One thing to be aware of with the vertical PDUs is where they get mounted. We've had lots of success with both APC and Baytech units. A lot of the Baytech units ONLY have RS-232. Ditto on the mounting issues with the vertical -- deeper and/or wider cabinets seem to reduce a lot of the pain. On our next buildout we're looking at the Panduit CS1 cabinets which are both deeper and wider. --D From DaveHowe at gmx.co.uk Thu Sep 25 13:09:58 2008 From: DaveHowe at gmx.co.uk (Dave Howe) Date: Thu, 25 Sep 2008 19:09:58 +0100 Subject: breadcrumbs and collusion In-Reply-To: <20080925173715.GA16314@vacation.karoshi.com.> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> <20080925154222.GA5514@isc.org> <48DBBED0.4020507@justinshore.com> <20080925170651.GB31947@infiltrated.net> <20080925173715.GA16314@vacation.karoshi.com.> Message-ID: <48DBD3F6.2060907@gmx.co.uk> bmanning at vacation.karoshi.com wrote: > NANOG makes a fine archive of discoverable material in a court case > intending to show collusion to drive folks out of business. > One presumes that each ISP here has some form of AUP and rules on > self-preservation roughly along the lines of "if there is material > impact to my network or my customers, I can do whatever it takes to > mitigate the traffic/intrusion". One does not need to collaberate > with others before enforcing your own AUP. Surely. However, it makes little sense to close your gate to keep the stray dogs out of your yard, if they can just come in via your neighbour's gate and climb over the fences. And having to post armed guards on the fences (because there are too many places to climb over) is no substitute for trustworthy neighbours who keep their own yards in order, plus its good neighbourliness, if you have had to shut your gate, to warn your neighbours they might need to keep an eye on theirs. From aaron.glenn at gmail.com Thu Sep 25 13:14:21 2008 From: aaron.glenn at gmail.com (Aaron Glenn) Date: Thu, 25 Sep 2008 11:14:21 -0700 Subject: a vernier of civilization... In-Reply-To: <58B1BC8C-19D5-46A1-A313-9A3B04F8112C@netconsonance.com> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> <58B1BC8C-19D5-46A1-A313-9A3B04F8112C@netconsonance.com> Message-ID: <18f601940809251114q15ed29edl3e2a96c6b2453042@mail.gmail.com> On Wed, Sep 24, 2008 at 10:48 PM, Jo Rhett wrote: > On Sep 24, 2008, at 7:24 PM, Randy Bush wrote: >> >> this way lies lynch mobs >> shall we at least apply a vernier of civilization? > > > Randy, I would agree if anything less had ever been effective. > > If you have a better idea, please explain to the rest of us. "we are a nation of laws, not men" From sil at infiltrated.net Thu Sep 25 13:18:09 2008 From: sil at infiltrated.net (J. Oquendo) Date: Thu, 25 Sep 2008 13:18:09 -0500 Subject: breadcrumbs and collusion In-Reply-To: <20080925173715.GA16314@vacation.karoshi.com.> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> <20080925154222.GA5514@isc.org> <48DBBED0.4020507@justinshore.com> <20080925170651.GB31947@infiltrated.net> <20080925173715.GA16314@vacation.karoshi.com.> Message-ID: <20080925181808.GA33247@infiltrated.net> On Thu, 25 Sep 2008, bmanning at vacation.karoshi.com wrote: > > NANOG makes a fine archive of discoverable material in a court case > intending to show collusion to drive folks out of business. > > One presumes that each ISP here has some form of AUP and rules on > self-preservation roughly along the lines of "if there is material > impact to my network or my customers, I can do whatever it takes to > mitigate the traffic/intrusion". One does not need to collaberate > with others before enforcing your own AUP. > > > --bill If we were to stick to the rules: It should also, and very notably, define what sanctions will be applied if a user breaks the AUP. Compliance with this policy should, as usual, be measured by regular audits. However, AUP's aren't a definitive mandatory or regulatory control they're CYA (Cover Your Ass) based and have been known to be put in place solely for that purpose. It IS your own backyard, but what about the contractual agreements that can potentially be broken when "oops I didn't know I was nullrouting that business because it passes through that AS" occurs. Are you willing to simply say "it's a matter of my opinion/judgement regardless if people like it or not". What happens to that potential agreement. I'm not siding with anyone here, I despise spammers, malware sites as much as anyone else, but I think this process of "pull the plug" needs to be reviewed fairly and accurately. Else how would you like it if my attitude veered towards "Well gee, AS32042332498732 never audited their network, now look at this filth, gee might as well block them too" Since many would like to justify their argument based on the "It's my party and I'll cry if I want to" theme, then imagine the potential damage if everyone took this attitude. How many networks would break? Who here votes to cut off some major AS's? Everybody's Internet, Rackspace maybe? I can give a list of some major organizations as can others that flagrantly allow things to go on. I see no mention of throwing these businesses into Salems Lot 2008. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, CNDA, CHFI, OSCP "A good district attorney can indict a ham sandwich if he wants to ... The accusations harm as much as the convictions ... they're obviously harmful or it wouldn't be news.." - John Carter wget -qO - www.infiltrated.net/sig|perl http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3AC173DB From Valdis.Kletnieks at vt.edu Thu Sep 25 13:26:28 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 25 Sep 2008 14:26:28 -0400 Subject: Where to move the Intercage/Atrivo discussion (was: the Intercage mess) In-Reply-To: Your message of "Thu, 25 Sep 2008 12:06:51 CDT." <20080925170651.GB31947@infiltrated.net> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> <20080925154222.GA5514@isc.org> <48DBBED0.4020507@justinshore.com> <20080925170651.GB31947@infiltrated.net> Message-ID: <30806.1222367188@turing-police.cc.vt.edu> On Thu, 25 Sep 2008 12:06:51 CDT, "J. Oquendo" said: > backyard protesting "Oh no you don't!". "A man's judgement > cannot be better than the information on which he has based it" > Arthur Sulzberger Of course, *all* providers execute some form of due diligence before accepting a new customer, such as Googling for them to see if the customer has a long history either good or bad, right? Of course, there's a discount carpet dealer in the area, has a big sign out front "We will not be knowingly undersold". Nice wording, that... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From bmanning at vacation.karoshi.com Thu Sep 25 13:39:42 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 25 Sep 2008 18:39:42 +0000 Subject: carpet sellers In-Reply-To: <30806.1222367188@turing-police.cc.vt.edu> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> <20080925154222.GA5514@isc.org> <48DBBED0.4020507@justinshore.com> <20080925170651.GB31947@infiltrated.net> <30806.1222367188@turing-police.cc.vt.edu> Message-ID: <20080925183942.GA16890@vacation.karoshi.com.> On Thu, Sep 25, 2008 at 02:26:28PM -0400, Valdis.Kletnieks at vt.edu wrote: > > Of course, there's a discount carpet dealer in the area, has a big sign out > front "We will not be knowingly undersold". Nice wording, that... once burned, twice shy. --bill From morrowc.lists at gmail.com Thu Sep 25 13:54:37 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 25 Sep 2008 14:54:37 -0400 Subject: Where to move the Intercage/Atrivo discussion (was: the Intercage mess) In-Reply-To: <26006.1222361594@turing-police.cc.vt.edu> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> <20080925154222.GA5514@isc.org> <48DBBED0.4020507@justinshore.com> <26006.1222361594@turing-police.cc.vt.edu> Message-ID: <75cb24520809251154ueb67b7ated0a4c76f94fc76e@mail.gmail.com> On Thu, Sep 25, 2008 at 12:53 PM, wrote: > On Thu, 25 Sep 2008 11:39:44 CDT, Justin Shore said: >> group would be interested in knowing that whois.estdomains.com >> (83.171.76.99) is now being hosted by as31353 via as8997 (didn't we have > > Well, that didn't take long. so then ,the 8997 issues of last weekend WERE a test of capabilities?? :( From jgreco at ns.sol.net Thu Sep 25 14:21:10 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 25 Sep 2008 14:21:10 -0500 (CDT) Subject: rackmount managed PDUs In-Reply-To: <48DBC2CD.5060100@justinshore.com> from "Justin Shore" at Sep 25, 2008 11:56:45 AM Message-ID: <200809251921.m8PJLAhK081347@aurora.sol.net> > Justin M. Streiner wrote: > > I have some Tripp Lite PDUMH30NETs that work well and are reasonably > > priced, but they have a few quirks (no RS-232 console port, web > > interface seems to be a little shaky with Firefox, etc) that would > > become more annoying when scaled up to several rows of new rack > > footprints. I'm also open to using managed vertically mounted PDUs. > > The plan is for each footprint to have "A" and B" feeds, so two > > PDUMH30NETs would take up 4U per footprint, which is a bit much... I'll second the vote for APC, they make a flexible variety of products that all "feel" the same, but support widely varying configurations. > One thing to be aware of with the vertical PDUs is where they get > mounted. A number of vertical Emerson PDUs were purchased for our DC. > However only one of the Liebert cabinets was purchased with the 6" > extension on the rear. The PDUs mount on each side of the cabinet door > frame with the receptacles facing the opposing PDU. Ie, both PDUs face > inward towards each other, not towards the front or rear of the cabinet. > They stick out about 2" plus the power cords stick out at least > another 2", more depending on how hard you fight to force the power > cables into bundles and wire-tie them off to the frame. The rails of > the servers barely clear the PDUs. The cabling on the back of the > servers is made all the harder by the bundle of power cables in the way. > It's a difficult physical problem to work around. We've used a very successful similar configuration where an extra set of vertical mounting rails is used at the very back of the rack *just* for purposes of mounting the 0U strips. Most people usually dismiss this sort of configuration as impractical due to the increased difficulty of accessing rack screws for the backs of the servers. We have a "long bit" that we use with our power screwdrivers, it's 21" long and basically slides thru right behind the 0U strip. Rack ends up looking something like this, from-the-top view: http://www.sol.net/tmp/nanog/rack.gif Extra set of vertical rails (vertical rails in red) in the rear. To them is attached, up to two per side, 0U PDU's. Outlets face each other, which is not *great* from an airflow reduction point of view. We use cable lacing strips (blue) in between the rear rail sets. We're a velcro shop and this works out pretty well for us. For those times you need to get at the screws in the first rear set of rails that are holding a server, you can stick your "long bit" or an offset screwdriver in, because of course the set of rails holding the PDU's is square holed, and the only holes obstructed are the ones holding the 0U PDU's. The main advantage of this over the quoted suggestion would be that it sounds like the quoted suggestion is a hard mount to the rack, which probably obstructs screw access, and may only allow one strip per side, depending. Of course, all of this makes various assumptions about the available geometries. ... 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 rs at seastrom.com Thu Sep 25 14:28:45 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Thu, 25 Sep 2008 15:28:45 -0400 Subject: once again, network hardware vendors spamming... Message-ID: <86r678uis2.fsf@seastrom.com> Anyone else gotten mail from John Lucania at atlantixglobal.com today? He lists his phone numbers as: 770.582.7248 Direct and 404.287.2603 Cell Why not give him a ring (preferably on his cell phone, maybe tonight?) and tell him what you think of spammers? :-) -r From mhernand1 at comcast.net Thu Sep 25 14:33:53 2008 From: mhernand1 at comcast.net (manolo) Date: Thu, 25 Sep 2008 15:33:53 -0400 Subject: Fiberlight Message-ID: <48DBE7A1.4000506@comcast.net> All, At the company I work for we are looking to using Fiberlight in south Florida (Miami, Ft. Lauderdale). Any one here use them and can share some pros and cons? Thanks, Manolo From bambenek at gmail.com Thu Sep 25 14:36:28 2008 From: bambenek at gmail.com (John C. A. Bambenek) Date: Thu, 25 Sep 2008 14:36:28 -0500 Subject: Wall it off, make it go away In-Reply-To: References: Message-ID: So, wll you be turning off your firewall and removing your router passwords first to be the test case? On 9/25/08, michael.dillon at bt.com wrote: >> let's push this stuff back into the nation-states who sponsor >> it and then use treaties to wall it off inside those places. > > Let's not mince words. You want to wall off the Chinese and Russian > Internets because you believe that the reason so much cybercrime > originates there is for political reasons (state sponsorship) rather > than economic ones. Have you ever visited these countries (Moscow > and Beijing don't count) and seen how people live? There is a much > larger economic incentive than you can imagine. Using the exchange > rate figures from xe.com does not tell you how valuable an American > dollar is in those countries. You need to spend enough time in the > country to see how it costs to ride a bus, buy your lunch, etc. > > In fact, cybercrime originates abroad because the economic incentive > is so great in those countries, and their level of technical education > is high enough that they can actually build the distributed software > systems that they need to drive the flow of hard cash. > > Fiddling with router configs, or mail server configs, does not change > this. In fact, the economic incentive for a NANOG reader to block the > bad stuff is probably a lot lower than for the foreign bad guy to evade > your blocks. He will just route around your efforts. > > Economic and legal problems should be fixed in the economic and legal > system, not in network operations. People on this list would do more > good by supporting legal and economic efforts to fix the problem than > by tweaking their routers. Or by simply ignoring the problem because > it is a lot easier for law enforcement to hit a standing target. > > In any case, I don't believe that nation states sponsor cybercrime. Bad > guys > are found in every country and they will always act for their own > benefit > regardless of what laws or treaties may be put in place. Over the past > 15 years, it has been shown that network vigilantism does not work. If > anything, > this just makes cybercriminals stronger by forcing them to evolve their > systems, and by weeding out the less intelligent ones. > > --Michael Dillon > > -- Sent from Gmail for mobile | mobile.google.com From tim at yocum.org Thu Sep 25 14:47:59 2008 From: tim at yocum.org (Tim Yocum) Date: Thu, 25 Sep 2008 14:47:59 -0500 Subject: Atrivo/InterCage and associated threads Message-ID: <14b99b330809251247v3b02893ej7acd63a38e8f64bd@mail.gmail.com> All, While it could be said that there are operational tidbits in some of the messages regarding InterCage and Atrivo, the discussion has veered off into various conversations including legalities and the Internet death penalty. While many of these topics are valid discussion points, they are not on-topic for NANOG. Accordingly, the MLC would like to ask that further replies to the InterCage/Atrivo discussion be taken to more appropriate venues. Thank you! - Tim, for the MLC From brandon at rd.bbc.co.uk Thu Sep 25 15:03:10 2008 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Thu, 25 Sep 2008 21:03:10 +0100 (BST) Subject: carpet sellers Message-ID: <200809252003.VAA11317@sunf10.rd.bbc.co.uk> > > Of course, there's a discount carpet dealer in the area, has a big sign out > > front "We will not be knowingly undersold". Nice wording, that... > > once burned, twice shy. A modern version, to paraphrase a world leader "trust you once, I'm the fool. Trust you... can't get trust again" brandon From smiley at zo.com Thu Sep 25 16:01:03 2008 From: smiley at zo.com (Michael Smiley) Date: Thu, 25 Sep 2008 14:01:03 -0700 Subject: rackmount managed PDUs In-Reply-To: <80e7195b0809251040we535233q95ae9fc09815ea9b@mail.gmail.com> References: <48DBC2CD.5060100@justinshore.com> <80e7195b0809251040we535233q95ae9fc09815ea9b@mail.gmail.com> Message-ID: <54ea498f0809251401y385e9778q6febc47623c7e37f@mail.gmail.com> I am a huge fan of the Avocent/Cyclades gear for its integration with the serial console servers. They do grouping, and alerts over SNMP/SMS/email. But the big seller for me is the integration. On Thu, Sep 25, 2008 at 10:40 AM, Duane Waddle wrote: > On Thu, Sep 25, 2008 at 11:56 AM, Justin Shore > wrote: > > > > Justin M. Streiner wrote: > > > > One thing to be aware of with the vertical PDUs is where they get > mounted. > > We've had lots of success with both APC and Baytech units. A lot of > the Baytech units ONLY have RS-232. Ditto on the mounting issues with > the vertical -- deeper and/or wider cabinets seem to reduce a lot of > the pain. On our next buildout we're looking at the Panduit CS1 > cabinets which are both deeper and wider. > > --D > > -- - Mike Smiley - smiley at zo.com - http://www.mikies.net From bonomi at mail.r-bonomi.com Thu Sep 25 16:27:13 2008 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Thu, 25 Sep 2008 16:27:13 -0500 (CDT) Subject: the Intercage mess Message-ID: <200809252127.m8PLRDCc008666@mail.r-bonomi.com> > From nanog-bounces at nanog.org Thu Sep 25 10:45:34 2008 > Date: Thu, 25 Sep 2008 08:42:22 -0700 > From: "David W. Hankins" > To: nanog at nanog.org > Subject: Re: the Intercage mess > > > On Thu, Sep 25, 2008 at 11:24:17AM +0900, Randy Bush wrote: > > John Bambenek wrote: > > > shall we at least apply a veneer of civilization? > > I think the current state of the art in civilized, peaceful, > extralegal negotiation of reasonable behaviour expected of businessmen > and their peers is a form of social ostracism given its name in 1880 > when the Irish Land League bade everyone in Mayo county, Ireland not > to engage economically or otherwise with Captain Charles Boycott...a > land owner who had set his rent very high, and was evicting anyone who > deigned to complain of it (fully within his legal authority, but > outside the realms of what the people saw as reasonable). > > If anyone can think of better, we'll have to call it "Intercaging". If someone were to slap a light-hearted name on the matter, could that be considered Atrivio-al mistake? *groan* From gherbert at retro.com Thu Sep 25 16:31:11 2008 From: gherbert at retro.com (George William Herbert) Date: Thu, 25 Sep 2008 14:31:11 -0700 Subject: DSL at MAE-East Message-ID: <200809252131.m8PLVBUP007828@kw.retro.com> Is there anyone who has successfully gotten DSL for out of band back channel into the MAE-East building? We're being told it's impossible, and somehow this strikes me as somewhat improbable... Thanks. -george william herbert gherbert at retro.com From drew.linsalata at gmail.com Thu Sep 25 16:52:34 2008 From: drew.linsalata at gmail.com (Drew Linsalata) Date: Thu, 25 Sep 2008 17:52:34 -0400 Subject: DSL at MAE-East In-Reply-To: <200809252131.m8PLVBUP007828@kw.retro.com> References: <200809252131.m8PLVBUP007828@kw.retro.com> Message-ID: On Sep 25, 2008, at 5:31 PM, George William Herbert wrote: > > Is there anyone who has successfully gotten DSL for out of band back > channel into the MAE-East building? > > We're being told it's impossible, and somehow this strikes me as > somewhat improbable... We're looking to do the same at Telx in NYC (60 Hudson - 9th floor). The folks at Telx that I've spoken to about it have been confused at best. From asr+nanog at latency.net Thu Sep 25 17:13:25 2008 From: asr+nanog at latency.net (Adam Rothschild) Date: Thu, 25 Sep 2008 18:13:25 -0400 Subject: rackmount managed PDUs In-Reply-To: References: Message-ID: <20080925221325.GB14022@latency.net> Another vote for APC here. We've deployed many hundreds in various receptacle configurations, and n'er any failures. The build quality is definite cut above the competition, some with interiors that look like they were assembled from duct tape and Radio Shack kits. :-) As a word to the wise once you make it past the purchasing stage, the software and IP stack is a bit fragile. No show-stoppers, mind you, just some items here and there which underscore the need for a proper management infrastructure and OSS. (For starters, you'll want to make sure you're running the latest firmware, as outlets and entire SNMP OID trees have been known to 'vanish' on earlier builds. Make sure they're ACLed tightly, as even the smallest amount of stray packets or concurrent access will make the unit unhappy. And if you need to provide "remote reboot" functionality to customers, create your own interface, or consider one the off-the-shelf solutions, Ubersmith DE being a popular choice, given the above constraints...) -a From surfer at mauigateway.com Thu Sep 25 17:21:17 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 25 Sep 2008 15:21:17 -0700 Subject: ASN 8997 again Message-ID: <20080925152117.79065ABF@resin14.mta.everyone.net> ------ morrowc.lists at gmail.com wrote: -------- From: "Christopher Morrow" On Thu, Sep 25, 2008 at 12:53 PM, wrote: > On Thu, 25 Sep 2008 11:39:44 CDT, Justin Shore said: >> group would be interested in knowing that whois.estdomains.com >> (83.171.76.99) is now being hosted by as31353 via as8997 (didn't we have > > Well, that didn't take long. so then ,the 8997 issues of last weekend WERE a test of capabilities?? :( -------------------------------------------------- That is indeed worrisome. Maybe my previous trigger happy -ness was ok? :-) I originally thought it was a testing of the waters for further intrusions into OPNs, now this. Still, I will try not to attribute to maliciousness that which could be explained by stupidity. scott From matthew at eeph.com Thu Sep 25 17:28:44 2008 From: matthew at eeph.com (Matthew Kaufman) Date: Thu, 25 Sep 2008 15:28:44 -0700 Subject: DSL at MAE-East In-Reply-To: <200809252131.m8PLVBUP007828@kw.retro.com> References: <200809252131.m8PLVBUP007828@kw.retro.com> Message-ID: <221181C7-D55F-4B11-98EE-B6C73399E61C@eeph.com> Why would it not be better to get an Ethernet cross-connect to someone in the facility who might be willing to charge you "DSL prices" for that kind of usage? (you'll pay for a cross-connect anyway) Matthew Kaufman (Sent from my iPhone) On Sep 25, 2008, at 2:31 PM, George William Herbert wrote: > > Is there anyone who has successfully gotten DSL for out of band back > channel into the MAE-East building? > > We're being told it's impossible, and somehow this strikes me as > somewhat improbable... > > Thanks. > > > -george william herbert > gherbert at retro.com > > From mike.lyon at gmail.com Thu Sep 25 17:32:14 2008 From: mike.lyon at gmail.com (Mike Lyon) Date: Thu, 25 Sep 2008 15:32:14 -0700 Subject: DSL at MAE-East In-Reply-To: <221181C7-D55F-4B11-98EE-B6C73399E61C@eeph.com> References: <200809252131.m8PLVBUP007828@kw.retro.com> <221181C7-D55F-4B11-98EE-B6C73399E61C@eeph.com> Message-ID: <1b5c1c150809251532if264ae8w73b0a300a686a347@mail.gmail.com> Or get an ISR with a 3G GSM card? On Thu, Sep 25, 2008 at 3:28 PM, Matthew Kaufman wrote: > Why would it not be better to get an Ethernet cross-connect to someone in > the facility who might be willing to charge you "DSL prices" for that kind > of usage? (you'll pay for a cross-connect anyway) > > Matthew Kaufman > > (Sent from my iPhone) > > On Sep 25, 2008, at 2:31 PM, George William Herbert > wrote: > >> >> Is there anyone who has successfully gotten DSL for out of band back >> channel into the MAE-East building? >> >> We're being told it's impossible, and somehow this strikes me as >> somewhat improbable... >> >> Thanks. >> >> >> -george william herbert >> gherbert at retro.com >> >> > > From kelly at hawknetworks.com Thu Sep 25 17:33:30 2008 From: kelly at hawknetworks.com (Kelly Kane) Date: Thu, 25 Sep 2008 15:33:30 -0700 Subject: rackmount managed PDUs In-Reply-To: <80e7195b0809251040we535233q95ae9fc09815ea9b@mail.gmail.com> References: <48DBC2CD.5060100@justinshore.com> <80e7195b0809251040we535233q95ae9fc09815ea9b@mail.gmail.com> Message-ID: <76c6c0530809251533kd558bc9k2a3d925a1c7ae126@mail.gmail.com> On Thu, Sep 25, 2008 at 10:40 AM, Duane Waddle wrote: > We've had lots of success with both APC and Baytech units. A lot of > the Baytech units ONLY have RS-232. I would like to register a strong vote against APC units. They are quite fragile in our experience, to the point of 20% DOA on their 0U managed units. Either the management console wouldn't work, or the relays were stuck in one position (on or off). Real pain in the neck. Their RS-232 port is RJ11 as well. Baytech's however provide pretty much everything we want, and are cheaper plus more reliable to boot! We only have experience with their RS-232 models, but the interface is easily scripted, customizable alarm threshold, and come out of the box ready to go. Our biggest issue with them so far is a batch of them came in with the threshold set to 12A instead of 16A. Kelly From brandon.galbraith at gmail.com Thu Sep 25 17:36:07 2008 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Thu, 25 Sep 2008 17:36:07 -0500 Subject: DSL at MAE-East In-Reply-To: <1b5c1c150809251532if264ae8w73b0a300a686a347@mail.gmail.com> References: <200809252131.m8PLVBUP007828@kw.retro.com> <221181C7-D55F-4B11-98EE-B6C73399E61C@eeph.com> <1b5c1c150809251532if264ae8w73b0a300a686a347@mail.gmail.com> Message-ID: <366100670809251536o5632b097qd39e20989d35d609@mail.gmail.com> On 9/25/08, Mike Lyon wrote: > > Or get an ISR with a 3G GSM card? I'm a fan of this solution. We use T-Mobile with EDGE cards (not 3G, but I don't need 3G for SSH, RDP, etc) in several of our colocation environments for remote access. At $30/month for the service (per card), it was way cheaper than a cross-connect and DSL service. Also fairly reliable. -brandon From matthew at eeph.com Thu Sep 25 17:36:31 2008 From: matthew at eeph.com (Matthew Kaufman) Date: Thu, 25 Sep 2008 15:36:31 -0700 Subject: DSL at MAE-East In-Reply-To: <1b5c1c150809251532if264ae8w73b0a300a686a347@mail.gmail.com> References: <200809252131.m8PLVBUP007828@kw.retro.com> <221181C7-D55F-4B11-98EE-B6C73399E61C@eeph.com> <1b5c1c150809251532if264ae8w73b0a300a686a347@mail.gmail.com> Message-ID: I thought of that too right after I hit send... But I don't see many scenarios where that is any better Matthew Kaufman (Sent from my iPhone) On Sep 25, 2008, at 3:32 PM, "Mike Lyon" wrote: > Or get an ISR with a 3G GSM card? > > On Thu, Sep 25, 2008 at 3:28 PM, Matthew Kaufman > wrote: >> Why would it not be better to get an Ethernet cross-connect to >> someone in >> the facility who might be willing to charge you "DSL prices" for >> that kind >> of usage? (you'll pay for a cross-connect anyway) >> >> Matthew Kaufman >> >> (Sent from my iPhone) >> >> On Sep 25, 2008, at 2:31 PM, George William Herbert > > >> wrote: >> >>> >>> Is there anyone who has successfully gotten DSL for out of band back >>> channel into the MAE-East building? >>> >>> We're being told it's impossible, and somehow this strikes me as >>> somewhat improbable... >>> >>> Thanks. >>> >>> >>> -george william herbert >>> gherbert at retro.com >>> >>> >> >> From davediaz at gmail.com Thu Sep 25 17:37:59 2008 From: davediaz at gmail.com (David Diaz) Date: Thu, 25 Sep 2008 18:37:59 -0400 Subject: DSL at MAE-East In-Reply-To: References: <200809252131.m8PLVBUP007828@kw.retro.com> Message-ID: <9F1C03C1-3F75-4B61-8BCD-107826C9311A@gmail.com> Check out http://www.wiredskies.com/CoLo-EVDO_ep_117.html It's a neat solution where for less then DSL you can get out of band over evdo to all your console ports/ethernet, and it also gives you a POTS line over the evdo. I commented on how this was needed for years and Chris Cook over there actually went out and built this neat box. I believe it runs about $35-40 MRC and it's a much quicker way to upload new code then a pots line. Neat part is if it works you do not pay the carrier hotel a cross connect MRC fee. That adds up rapidly. David On Sep 25, 2008, at 5:52 PM, Drew Linsalata wrote: > > On Sep 25, 2008, at 5:31 PM, George William Herbert wrote: > >> >> Is there anyone who has successfully gotten DSL for out of band back >> channel into the MAE-East building? >> >> We're being told it's impossible, and somehow this strikes me as >> somewhat improbable... > > > We're looking to do the same at Telx in NYC (60 Hudson - 9th > floor). The folks at Telx that I've spoken to about it have been > confused at best. > > > From cholland at rnmd.net Thu Sep 25 17:38:26 2008 From: cholland at rnmd.net (Craig Holland) Date: Thu, 25 Sep 2008 17:38:26 -0500 Subject: ARIN Routing Registry vs RADB vs X Message-ID: <3FEEC5BE16966148B912DEB0FF34C81C7B2246@BE09.exg4.exghost.com> Hi, I recently ran across a situation where a large ISP only accepts IRR entries generated by RADB to build their path filters. I use the ARIN Routing Registry. Is this a common practice? Should I convert over to RADB? Thanks, Craig From dhubbard at dino.hostasaurus.com Thu Sep 25 17:39:41 2008 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Thu, 25 Sep 2008 18:39:41 -0400 Subject: DSL at MAE-East Message-ID: From: Brandon Galbraith [mailto:brandon.galbraith at gmail.com] > > I'm a fan of this solution. We use T-Mobile with EDGE cards > (not 3G, but I don't need 3G for SSH, RDP, etc) in several > of our colocation environments for remote access. At > $30/month for the service (per card), it was way cheaper > than a cross-connect and DSL service. Also fairly reliable. What equipment do you guys use in the facility to do this? I hadn't through of this before but between the phone line itself and the ds1 cross connect, we're spending like $200/month for each emergency dial-up line. Thanks, David From gherbert at retro.com Thu Sep 25 17:35:46 2008 From: gherbert at retro.com (George William Herbert) Date: Thu, 25 Sep 2008 15:35:46 -0700 Subject: DSL at MAE-East In-Reply-To: References: <200809252131.m8PLVBUP007828@kw.retro.com> <221181C7-D55F-4B11-98EE-B6C73399E61C@eeph.com> <1b5c1c150809251532if264ae8w73b0a300a686a347@mail.gmail.com> Message-ID: <200809252235.m8PMZkWK010140@kw.retro.com> > Matthew: >> Mike Lyon: >>> Matthew: >>>> George: > >>>> Is there anyone who has successfully gotten DSL for out of band back > >>> Why would it not be better to get an Ethernet cross-connect to > >> Or get an ISR with a 3G GSM card? > > >I thought of that too right after I hit send... But I don't see many >scenarios where that is any better Somewhat less likely to have common mode (backhoe, etc) failures if it's DSL (or a 3G GSM or so forth). We had a two-provider common mode failure at another site, and I've had several in the past at other clients, one of which made it onto CNN... So I now try to provision something more resistant to that. Note "resistant" not proof - I've also had enough "got groomed together" failures including the uplinks for DSL providers and cell providers to believe that these are truly guaranteed independent. But we're trying to do an acceptably reliably separated choice without going to Iridium or Hughesnet. -george william herbert gherbert at retro.com From davids at webmaster.com Thu Sep 25 17:51:21 2008 From: davids at webmaster.com (David Schwartz) Date: Thu, 25 Sep 2008 15:51:21 -0700 Subject: ARIN Routing Registry vs RADB vs X In-Reply-To: <3FEEC5BE16966148B912DEB0FF34C81C7B2246@BE09.exg4.exghost.com> Message-ID: > Hi, > > I recently ran across a situation where a large ISP only accepts IRR > entries generated by RADB to build their path filters. I use the ARIN > Routing Registry. Is this a common practice? Should I convert over to > RADB? > > Thanks, > Craig Since 2002, the RADB has included entries that originate with ARIN. The RADB also includes records from numerous other databases. That's what the 'source:' tag is for. Are you saying the ISP only accepts entries they can pull from the RADB? Or only entries that originate with the RADB? If the former, you're fine. Your ARIN records are in the RADB. DS From christian at broknrobot.com Thu Sep 25 17:53:18 2008 From: christian at broknrobot.com (Christian Koch) Date: Thu, 25 Sep 2008 18:53:18 -0400 Subject: ARIN Routing Registry vs RADB vs X In-Reply-To: <3FEEC5BE16966148B912DEB0FF34C81C7B2246@BE09.exg4.exghost.com> References: <3FEEC5BE16966148B912DEB0FF34C81C7B2246@BE09.exg4.exghost.com> Message-ID: Sounds ridiculous...radb mirrors arins db, I don't see why they are trying to force you to use radb. You can query whois.radb.net and you will be able to see your arin objects... Did they give you a reason on WHY you should have to use RADB? Christian On Thu, Sep 25, 2008 at 6:38 PM, Craig Holland wrote: > Hi, > > I recently ran across a situation where a large ISP only accepts IRR > entries generated by RADB to build their path filters. I use the ARIN > Routing Registry. Is this a common practice? Should I convert over to > RADB? > > Thanks, > Craig > > > From mike.lyon at gmail.com Thu Sep 25 17:54:21 2008 From: mike.lyon at gmail.com (Mike Lyon) Date: Thu, 25 Sep 2008 15:54:21 -0700 Subject: DSL at MAE-East In-Reply-To: <200809252235.m8PMZkWK010140@kw.retro.com> References: <200809252131.m8PLVBUP007828@kw.retro.com> <221181C7-D55F-4B11-98EE-B6C73399E61C@eeph.com> <1b5c1c150809251532if264ae8w73b0a300a686a347@mail.gmail.com> <200809252235.m8PMZkWK010140@kw.retro.com> Message-ID: <1b5c1c150809251554i5074336vd30dfd42e33f09d4@mail.gmail.com> For an absolute base model, you could get the Cisco ISR 881. On Thu, Sep 25, 2008 at 3:35 PM, George William Herbert wrote: > >> Matthew: >>> Mike Lyon: >>>> Matthew: >>>>> George: >> >>>>> Is there anyone who has successfully gotten DSL for out of band back >> >>>> Why would it not be better to get an Ethernet cross-connect to >> >>> Or get an ISR with a 3G GSM card? >> >> >>I thought of that too right after I hit send... But I don't see many >>scenarios where that is any better > > Somewhat less likely to have common mode (backhoe, etc) failures if > it's DSL (or a 3G GSM or so forth). > > We had a two-provider common mode failure at another site, and I've had > several in the past at other clients, one of which made it onto CNN... > So I now try to provision something more resistant to that. > > Note "resistant" not proof - I've also had enough "got groomed together" > failures including the uplinks for DSL providers and cell providers to > believe that these are truly guaranteed independent. But we're trying > to do an acceptably reliably separated choice without going to Iridium > or Hughesnet. > > > -george william herbert > gherbert at retro.com > > > From cholland at rnmd.net Thu Sep 25 17:55:40 2008 From: cholland at rnmd.net (Craig Holland) Date: Thu, 25 Sep 2008 17:55:40 -0500 Subject: ARIN Routing Registry vs RADB vs X In-Reply-To: References: <3FEEC5BE16966148B912DEB0FF34C81C7B2246@BE09.exg4.exghost.com> Message-ID: <3FEEC5BE16966148B912DEB0FF34C81C7B2249@BE09.exg4.exghost.com> Hi... > Are you saying the ISP only accepts entries they can pull from the RADB? > Or > only entries that originate with the RADB? ...ones that only originate from RADB. This is the part that I found strange considering the ARIN records are in (show up in) RADB and they are what most would consider a trusted source. CH > If the former, you're fine. > Your > ARIN records are in the RADB. > > DS > > > From bmanning at vacation.karoshi.com Thu Sep 25 17:54:42 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 25 Sep 2008 22:54:42 +0000 Subject: ARIN Routing Registry vs RADB vs X In-Reply-To: <3FEEC5BE16966148B912DEB0FF34C81C7B2246@BE09.exg4.exghost.com> References: <3FEEC5BE16966148B912DEB0FF34C81C7B2246@BE09.exg4.exghost.com> Message-ID: <20080925225442.GA1752@vacation.karoshi.com.> On Thu, Sep 25, 2008 at 05:38:26PM -0500, Craig Holland wrote: > Hi, > > I recently ran across a situation where a large ISP only accepts IRR > entries generated by RADB to build their path filters. I use the ARIN > Routing Registry. Is this a common practice? Should I convert over to > RADB? > > Thanks, > Craig > > use of a single RR has almost never been a good idea... not since RIPE first split out of the RABD, 13 years ago. that said, several of the RIR's are planning/testing a new suite of tools to do crypto-authentication of route objects (the IETF SIDR work). APNIC might be in beta as early as this year and I think ARIN will be doing some trial work in 2h09. ostensibly, this will be a much stronger toolset on which to base route accuracy/acceptance. You might want to ask about it at the upcoming ARIN mtg in LA... Its right after the NANOG mtg. --bill From brandon at rd.bbc.co.uk Thu Sep 25 17:57:06 2008 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Thu, 25 Sep 2008 23:57:06 +0100 (BST) Subject: rackmount managed PDUs Message-ID: <200809252257.XAA02741@sunf10.rd.bbc.co.uk> I've used http://www.audionics.co.uk/products/emu.htm but for new installs I'm looking at http://web2.raritan.adxstudio.com/products/power-management/Dominion-PX/DPCR20A-32/ for the per port power consumption data, increasingly important with UK colo power price increases I'm not a fan of zero U devices unless you get racks they're designed for as they get in the way of other cabling and server rails (protruding parts seem to be common with some manufacturers rails) and make any work risky brandon From cholland at rnmd.net Thu Sep 25 17:57:20 2008 From: cholland at rnmd.net (Craig Holland) Date: Thu, 25 Sep 2008 17:57:20 -0500 Subject: ARIN Routing Registry vs RADB vs X In-Reply-To: References: <3FEEC5BE16966148B912DEB0FF34C81C7B2246@BE09.exg4.exghost.com> Message-ID: <3FEEC5BE16966148B912DEB0FF34C81C7B224A@BE09.exg4.exghost.com> They gave no particular reason. I figured I'd ask ya'all before I started to push back and use phrases like 'silly', 'ridiculous', and 'pointless' in my argument to them. Thanks, Craig > -----Original Message----- > From: Christian Koch [mailto:christian at broknrobot.com] > Sent: Thursday, September 25, 2008 3:53 PM > To: Craig Holland > Cc: nanog at merit.edu > Subject: Re: ARIN Routing Registry vs RADB vs X > > Sounds ridiculous...radb mirrors arins db, I don't see why they are > trying to force you to use radb. > > You can query whois.radb.net and you will be able to see your arin > objects... > > Did they give you a reason on WHY you should have to use RADB? > > > Christian > > > > On Thu, Sep 25, 2008 at 6:38 PM, Craig Holland wrote: > > Hi, > > > > I recently ran across a situation where a large ISP only accepts IRR > > entries generated by RADB to build their path filters. I use the ARIN > > Routing Registry. Is this a common practice? Should I convert over to > > RADB? > > > > Thanks, > > Craig > > > > > > From term at northnet.net.nz Thu Sep 25 17:58:03 2008 From: term at northnet.net.nz (Term) Date: Fri, 26 Sep 2008 10:58:03 +1200 Subject: DDoS from theplanet.com Message-ID: <20080925230127.6ADDE10BDD2@mx0.northnet.net.nz> Hi, Is there anyone on this list that can give me a noc/security contact for someone at theplanet.com I have been getting a DDos from servers hosted with them for the past 60 hours and they seem to have the care factor of 0 Thanks Term From christopher.morrow at gmail.com Thu Sep 25 18:30:55 2008 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Thu, 25 Sep 2008 19:30:55 -0400 Subject: DDoS from theplanet.com In-Reply-To: <20080925230127.6ADDE10BDD2@mx0.northnet.net.nz> References: <20080925230127.6ADDE10BDD2@mx0.northnet.net.nz> Message-ID: <75cb24520809251630x1bfa9b1dw964d70129deeac39@mail.gmail.com> If you have some specifics I can pass them along On 9/25/08, Term wrote: > Hi, > > Is there anyone on this list that can give me a noc/security contact > for someone at theplanet.com > > I have been getting a DDos from servers hosted with them for the past 60 > hours > and they seem to have the care factor of 0 > > Thanks > Term > > > -- Sent from my mobile device From kamal.mehta at us.ibm.com Thu Sep 25 18:59:06 2008 From: kamal.mehta at us.ibm.com (Kamal Mehta) Date: Thu, 25 Sep 2008 17:59:06 -0600 Subject: AUTO: Kamal Mehta is on vacation (returning 09/29/2008) Message-ID: I am out of the office until 09/29/2008. I am on vacation and will not have access to e-mail. I will try to reply to your message on my return. If you need immediate assistance, please call the IBM AOD Service Center at 877-737-3700. Note: This is an automated response to your message "NANOG Digest, Vol 8, Issue 118" sent on 9/25/08 16:56:09. This is the only notification you will receive while this person is away. From noel.butler at ausics.net Thu Sep 25 19:06:08 2008 From: noel.butler at ausics.net (Noel Butler) Date: Fri, 26 Sep 2008 10:06:08 +1000 Subject: MTA Survey In-Reply-To: <48DBA6F0.2090805@karnaugh.za.net> References: <1222326691.29270.10.camel@roswell.ausics.net> <48DB3D04.4050302@karnaugh.za.net> <1222331303.20200.1411.camel@petrie.sacredspiral.co.uk> <70D072392E56884193E3D2DE09C097A9F5FB@pascal.zaphodb.org> <48DBA6F0.2090805@karnaugh.za.net> Message-ID: <1222387568.2727.12.camel@roswell.ausics.net> On Fri, 2008-09-26 at 00:57, Colin Alston wrote: > Tomas L. Byrnes wrote: > > Or the highly likely scenario that the primary gateway accessible to the > > survey tool is some load balanced SPAM filtering cluster, and not the > > MTA in use as final delivery. > > > > Good point, real MTA in front of Excange is extremely common.. My spam filters seem to have eaten most posts in this thread :) I have always believed in real humans casting votes for what they favour, in place of some bot that scans mail servers and can return stupid results like PIX etc which obviously is not the mail server, sure this could also be sent to exim/postfix etc mailing lists and see them all pop over to it, and I read via the archives someone posted about the OS base install, well, if thats what they left installed and using it, then why should their vote not count? The fact some of us might have 100's of mail servers, doesn't mean much at all, for instance, DMail, there might be 500 ISP's using it, they might have 50,000 DMail servers between them, this means little, as ultimately one person, somewhere in that organisation, decided DMail would be used in those 500 cases, be it for personal or functionality reasons, the fact 1 million corporate, Govt, and SOHO's decide to use Sendmail and Exim, means they each deserve 1 million votes, as 1 million people ultimately decided that's the MTA they would use, and I doubt those that are 'clueless' and just use it for sake of using it because it was installed, wouldn't give a rats about going to some poll anyway. Cheers :) From dts at senie.com Thu Sep 25 19:05:49 2008 From: dts at senie.com (Daniel Senie) Date: Thu, 25 Sep 2008 20:05:49 -0400 Subject: rackmount managed PDUs In-Reply-To: <20080925221325.GB14022@latency.net> References: <20080925221325.GB14022@latency.net> Message-ID: <200809260007.m8Q078uo021220@parsley.amaranth.net> At 06:13 PM 9/25/2008, Adam Rothschild wrote: >Another vote for APC here. We've deployed many hundreds in various >receptacle configurations, and n'er any failures. The build quality >is definite cut above the competition, some with interiors that look >like they were assembled from duct tape and Radio Shack kits. :-) > >As a word to the wise once you make it past the purchasing stage, the >software and IP stack is a bit fragile. No show-stoppers, mind you, >just some items here and there which underscore the need for a proper >management infrastructure and OSS. We've had issues with their code being fragile, failing to respond at times. Most recently, one of our AP7932's decided someone else was using the web interface and would not let me log in. Fortunately, I was simply checking on power consumption, not trying to reboot something. But it reminded me of a serious shortcoming. You can add user accounts so specific people can power cycle only their stuff, but the web interface appears to be limited to one user at a time, not very helpful. I'll probably wind up connecting the serial ports to a terminal server to ensure access (serial port seemed to still work when web, telnet and ssh refused the login). And we're looking at other brands as options for future deployments. Would be interested in hearing from folks who've tried the newest Raritan power stuff. >(For starters, you'll want to make sure you're running the latest >firmware, as outlets and entire SNMP OID trees have been known to >'vanish' on earlier builds. Make sure they're ACLed tightly, as even >the smallest amount of stray packets or concurrent access will make >the unit unhappy. And if you need to provide "remote reboot" >functionality to customers, create your own interface, or consider one >the off-the-shelf solutions, Ubersmith DE being a popular choice, >given the above constraints...) Ah, so yep, I see you've confirmed that concurrent access is a total non-starter with these, as I had guessed. Nice products, but agree their IP interfaces are lacking. And yes, you can hide them behind other software, just too bad you have to. Dan From ge at linuxbox.org Thu Sep 25 21:37:59 2008 From: ge at linuxbox.org (Gadi Evron) Date: Thu, 25 Sep 2008 21:37:59 -0500 (CDT) Subject: ASN 8997 again In-Reply-To: <20080925152117.79065ABF@resin14.mta.everyone.net> References: <20080925152117.79065ABF@resin14.mta.everyone.net> Message-ID: On Thu, 25 Sep 2008, Scott Weeks wrote: > > ------ morrowc.lists at gmail.com wrote: -------- > From: "Christopher Morrow" > On Thu, Sep 25, 2008 at 12:53 PM, wrote: >> On Thu, 25 Sep 2008 11:39:44 CDT, Justin Shore said: > >>> group would be interested in knowing that whois.estdomains.com >>> (83.171.76.99) is now being hosted by as31353 via as8997 (didn't we have >> >> Well, that didn't take long. > > so then ,the 8997 issues of last weekend WERE a test of capabilities?? :( > -------------------------------------------------- > > > > That is indeed worrisome. Maybe my previous trigger happy -ness was ok? :-) I originally thought it was a testing of the waters for further intrusions into OPNs, now this. Still, I will try not to attribute to maliciousness that which could be explained by stupidity. I want to say "don't attribute to malice..." but.. it seems like these things will become more common soon. Gadi. > scott > > From ge at linuxbox.org Thu Sep 25 21:39:02 2008 From: ge at linuxbox.org (Gadi Evron) Date: Thu, 25 Sep 2008 21:39:02 -0500 (CDT) Subject: DDoS from theplanet.com In-Reply-To: <20080925230127.6ADDE10BDD2@mx0.northnet.net.nz> References: <20080925230127.6ADDE10BDD2@mx0.northnet.net.nz> Message-ID: On Fri, 26 Sep 2008, Term wrote: > Hi, > > Is there anyone on this list that can give me a noc/security contact for > someone at theplanet.com > > I have been getting a DDos from servers hosted with them for the past 60 > hours > and they seem to have the care factor of 0 There are some good security people there in recent years, I am sure they are on it now. What contact did you use to try and reach them? > Thanks > Term > From Valdis.Kletnieks at vt.edu Thu Sep 25 21:53:32 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 25 Sep 2008 22:53:32 -0400 Subject: ASN 8997 again In-Reply-To: Your message of "Thu, 25 Sep 2008 15:21:17 PDT." <20080925152117.79065ABF@resin14.mta.everyone.net> References: <20080925152117.79065ABF@resin14.mta.everyone.net> Message-ID: <7821.1222397612@turing-police.cc.vt.edu> On Thu, 25 Sep 2008 15:21:17 PDT, Scott Weeks said: > That is indeed worrisome. Maybe my previous trigger happy -ness was ok? :-) > I originally thought it was a testing of the waters for further intrusions into > OPNs, now this. Still, I will try not to attribute to maliciousness that which > could be explained by stupidity. Only a complete blithering idiot would accept as a customer? Only a complete blithering idiot would accept routing announcements from ? Oh forget it, this is shooting fish in a barrel... The real problem is, of course, the truly vast number of providers that won't knowingly accept scum-of-the-earth as customers... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From nenolod at systeminplace.net Thu Sep 25 22:47:54 2008 From: nenolod at systeminplace.net (William Pitcock) Date: Thu, 25 Sep 2008 22:47:54 -0500 Subject: Cox DNS resolver engineers? Message-ID: <1222400874.20200.1468.camel@petrie.sacredspiral.co.uk> Hi, Anyone involved in Cox's DNS resolver engineering and maintainance: can you contact me off list to resolve some problems? Thanks! William From nanog-post at rsuc.gweep.net Thu Sep 25 23:02:22 2008 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Fri, 26 Sep 2008 00:02:22 -0400 Subject: ARIN Routing Registry vs RADB vs X In-Reply-To: <3FEEC5BE16966148B912DEB0FF34C81C7B224A@BE09.exg4.exghost.com> References: <3FEEC5BE16966148B912DEB0FF34C81C7B2246@BE09.exg4.exghost.com> <3FEEC5BE16966148B912DEB0FF34C81C7B224A@BE09.exg4.exghost.com> Message-ID: <20080926040222.GA8151@gweep.net> On Thu, Sep 25, 2008 at 05:57:20PM -0500, Craig Holland wrote: > They gave no particular reason. I figured I'd ask ya'all before I > started to push back and use phrases like 'silly', 'ridiculous', and > 'pointless' in my argument to them. Allow me: It is silly to attempt to use only a single registry-of-origin from the IRR mesh. If reading specifications is too difficult, a cursory reading of just the irr.net website shows how ridiculous such an implementation would be. Given the system is designed to be distributed, only eating a single origin is pointless. All that said, it is not uncommon for a provider who operates a proper routing registry to force all but the demonstrably clueful customers into theirs. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From randy at psg.com Thu Sep 25 23:18:24 2008 From: randy at psg.com (Randy Bush) Date: Fri, 26 Sep 2008 13:18:24 +0900 Subject: ARIN Routing Registry vs RADB vs X In-Reply-To: <20080926040222.GA8151@gweep.net> References: <3FEEC5BE16966148B912DEB0FF34C81C7B2246@BE09.exg4.exghost.com> <3FEEC5BE16966148B912DEB0FF34C81C7B224A@BE09.exg4.exghost.com> <20080926040222.GA8151@gweep.net> Message-ID: <48DC6290.1040409@psg.com> i think that what may have been glossed over here is that, if my memory serves, which it often does not, while a whois query to RADB will show mirrored entries from e.g. RGNET peval() to RADB will not yield those mirrored data this is a feature, not a bug, as one wants to order the peval() search. randy From christian at broknrobot.com Thu Sep 25 23:18:40 2008 From: christian at broknrobot.com (Christian Koch) Date: Fri, 26 Sep 2008 00:18:40 -0400 Subject: Cox DNS resolver engineers? In-Reply-To: <1222400874.20200.1468.camel@petrie.sacredspiral.co.uk> References: <1222400874.20200.1468.camel@petrie.sacredspiral.co.uk> Message-ID: a good place to get noc contact info is: as22773.peeringdb.com On Thu, Sep 25, 2008 at 11:47 PM, William Pitcock wrote: > Hi, > > Anyone involved in Cox's DNS resolver engineering and maintainance: can > you contact me off list to resolve some problems? > > Thanks! > > William > > > From ilopezlists at sandboxitsolutions.com Fri Sep 26 00:26:16 2008 From: ilopezlists at sandboxitsolutions.com (Israel Lopez) Date: Thu, 25 Sep 2008 22:26:16 -0700 Subject: Rackmount Vendors Message-ID: <48DC7278.9000103@sandboxitsolutions.com> Hey there, Anyone know of a good rackmount supplies vendor near the greater Los Angeles, CA area? Looking for a rack and some rackmount power strips if possible. Contact me off list. Thanks Much, Israel From orion at pirk.com Fri Sep 26 01:23:08 2008 From: orion at pirk.com (Steve Pirk) Date: Thu, 25 Sep 2008 23:23:08 -0700 (PDT) Subject: Rackmount Vendors In-Reply-To: <48DC7278.9000103@sandboxitsolutions.com> References: <48DC7278.9000103@sandboxitsolutions.com> Message-ID: Not to plug people I know, but Chatsworth Products Inc. I know they are the best in the area and supply lots of fairly large cusomers (my real job included). http://www.chatsworth.com/datacenter -- Steve Equal bytes for women. On Thu, 25 Sep 2008, Israel Lopez wrote: > Hey there, > > Anyone know of a good rackmount supplies vendor near the greater Los > Angeles, CA area? Looking for a rack and some rackmount power strips if > possible. > > Contact me off list. > > Thanks Much, > > Israel > From peter at peter-dambier.de Fri Sep 26 02:50:52 2008 From: peter at peter-dambier.de (Peter Dambier) Date: Fri, 26 Sep 2008 09:50:52 +0200 Subject: once again, network hardware vendors spamming... In-Reply-To: <86r678uis2.fsf@seastrom.com> References: <86r678uis2.fsf@seastrom.com> Message-ID: <48DC945C.2040407@peter-dambier.de> You can always excuse you are reading his add from the other side of the globe and did not know it was night over there :) Cheers Peter Robert E. Seastrom wrote: > Anyone else gotten mail from John Lucania at atlantixglobal.com today? > > He lists his phone numbers as: > > 770.582.7248 Direct > and > 404.287.2603 Cell > > Why not give him a ring (preferably on his cell phone, maybe tonight?) > and tell him what you think of spammers? :-) > > -r > -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: peter at peter-dambier.de http://www.peter-dambier.de/ http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ From michael.dillon at bt.com Fri Sep 26 04:59:28 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 26 Sep 2008 10:59:28 +0100 Subject: breadcrumbs and collusion In-Reply-To: <48DBD3F6.2060907@gmx.co.uk> Message-ID: > However, it makes little sense to close your gate to keep > the stray dogs out of your yard, if they can just come in via > your neighbour's gate and climb over the fences. It makes a lot of sense. Having closed your gate, and discovered a stray dog in your back yard, you can call the animal control people and they stand a good chance of catching that stray dog. However, if you tell all your neighbors to close their gates, the stray is still out there, animal control won't know where to find it, plus you and your neighbors now have to bear the perpetual cost of always keeping your gates closed. There are still many American towns where people don't even have fences around their yards. The difference is that by closing your gate (filtering announcements) you just shift the problem onto somebody else. But if you call the animal control (police) with evidence of wrongdoing, there is a chance to clean up the mess. And finally, history shows that closing your own gates and letting the bad guys run loose, never solves problems, just allows them to escalate. --Michael Dillon From tme at multicasttech.com Fri Sep 26 06:48:21 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 26 Sep 2008 07:48:21 -0400 Subject: once again, network hardware vendors spamming... In-Reply-To: <86r678uis2.fsf@seastrom.com> References: <86r678uis2.fsf@seastrom.com> Message-ID: <9D2F7191-F08B-4C74-81D9-D3CD32AFB6C7@multicasttech.com> Dear Robert; I feel that this is not appropriate for this list. Anyone on this list might have valid or nefarious reasons to wish to DOS someone else. This list is not an appropriate means of organizing that. I have not received such mail. I have no way of verifying whether or not you have. I don't know J.L. and don't even see him as a contributor to this list. Now, I know you, but there are way too many people on this list to know them all, or for them to all know you (or me, or anyone else). And, email addresses can be spoofed. And, not everyone reads NANOG faithfully all the time, so a spoof might not be detected for some time. I think you can see the potential for mischief here. Regards Marshall On Sep 25, 2008, at 3:28 PM, Robert E. Seastrom wrote: > > Anyone else gotten mail from John Lucania at atlantixglobal.com today? > > He lists his phone numbers as: > > 770.582.7248 Direct > and > 404.287.2603 Cell > > Why not give him a ring (preferably on his cell phone, maybe tonight?) > and tell him what you think of spammers? :-) > > -r > > From cidr-report at potaroo.net Fri Sep 26 07:00:04 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 26 Sep 2008 22:00:04 +1000 (EST) Subject: BGP Update Report Message-ID: <200809261200.m8QC049h082892@wattle.apnic.net> BGP Update Report Interval: 25-Aug-08 -to- 25-Sep-08 (32 days) Observation Point: BGP Peering with AS2.0 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9583 293291 3.5% 220.7 -- SIFY-AS-IN Sify Limited 2 - AS1803 109779 1.3% 81.6 -- ICMNET-5 - Sprint 3 - AS4538 104222 1.2% 20.7 -- ERX-CERNET-BKB China Education and Research Network Center 4 - AS5691 78349 0.9% 6026.8 -- MITRE-AS-5 - The MITRE Corporation 5 - AS8151 68816 0.8% 29.0 -- Uninet S.A. de C.V. 6 - AS9051 64130 0.8% 400.8 -- IDM Autonomous System 7 - AS6389 62409 0.7% 14.3 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 8 - AS4184 61060 0.7% 30530.0 -- STORTEK-WHQ - Storage Technology Corporation 9 - AS14593 51960 0.6% 51960.0 -- BRAND-INSTITUTE - Brand Instiute, Inc. 10 - AS209 49708 0.6% 10.4 -- ASN-QWEST - Qwest 11 - AS10396 49135 0.6% 701.9 -- COQUI-NET - DATACOM CARIBE, INC. 12 - AS4274 45008 0.5% 661.9 -- ERX-AU-NET Assumption University 13 - AS17488 42268 0.5% 28.9 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 14 - AS20115 41040 0.5% 22.8 -- CHARTER-NET-HKY-NC - Charter Communications 15 - AS30890 40002 0.5% 28.6 -- EVOLVA Evolva Telecom 16 - AS11971 39566 0.5% 5652.3 -- PFIZERNET-GROTON - PFIZER INC. 17 - AS8866 38036 0.5% 117.0 -- BTC-AS Bulgarian Telecommunication Company Plc. 18 - AS18231 36518 0.4% 146.7 -- EXATT-AS-AP IOL NETCOM LTD 19 - AS7018 34799 0.4% 23.5 -- ATT-INTERNET4 - AT&T WorldNet Services 20 - AS6458 33132 0.4% 91.8 -- Telgua TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS14593 51960 0.6% 51960.0 -- BRAND-INSTITUTE - Brand Instiute, Inc. 2 - AS4184 61060 0.7% 30530.0 -- STORTEK-WHQ - Storage Technology Corporation 3 - AS8266 14927 0.2% 14927.0 -- NEXUSTEL Nexus Telecommunications 4 - AS29910 7072 0.1% 7072.0 -- IACP - INTL. ASSN OF CHIEF OF POLICEI 5 - AS38180 6550 0.1% 6550.0 -- ETPI-IDS-JOLLIBEE-AS-AP 6/Fth floor JOLLIBEE PLAZA, Emerald Ave. Ortigas Center Pasig City. 6 - AS5691 78349 0.9% 6026.8 -- MITRE-AS-5 - The MITRE Corporation 7 - AS11971 39566 0.5% 5652.3 -- PFIZERNET-GROTON - PFIZER INC. 8 - AS43299 4660 0.1% 4660.0 -- TELECONTACT-AS Telecontact Ltd. 9 - AS4557 7872 0.1% 3936.0 -- EP0-BLK-ASNBLOCK-7 - EP.NET, LLC. 10 - AS23082 19333 0.2% 3866.6 -- MPHI - Michigan Public Health Institute 11 - AS30969 26572 0.3% 3321.5 -- TAN-NET TransAfrica Networks 12 - AS44194 3184 0.0% 3184.0 -- FREIFUNK-BERLIN-AS Freifunk Berlin 13 - AS23917 2247 0.0% 2247.0 -- BRIBIE-NET-AS-AP Bribie Island Net Multihomed, Brisbane 14 - AS24491 1774 0.0% 1774.0 -- WORLDWEB-THAILAND-AS-AP Internet Service Provider Thailand 15 - AS32011 1572 0.0% 1572.0 -- JOHO-NYC - Joho Capital, LLC 16 - AS9747 11612 0.1% 1451.5 -- EZINTERNET-AS-AP EZInternet Pty Ltd 17 - AS10221 5686 0.1% 1421.5 -- HEWLETT-PACKARD Multi-homed connections to multiple ISP's providing 18 - AS25321 1247 0.0% 1247.0 -- G4S-NET GROUP 4 SECURITAS Prague 19 - AS35287 2469 0.0% 1234.5 -- BGT-NOGLIKI-AS JSC BG Telecom Nogliki 20 - AS39843 2258 0.0% 1129.0 -- RATECOM-AS Joint Stock Company "Ratecom" TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 192.12.120.0/24 78240 0.9% AS5691 -- MITRE-AS-5 - The MITRE Corporation 2 - 210.214.151.0/24 61247 0.7% AS9583 -- SIFY-AS-IN Sify Limited 3 - 221.134.222.0/24 58908 0.7% AS9583 -- SIFY-AS-IN Sify Limited 4 - 194.126.143.0/24 55779 0.6% AS9051 -- IDM Autonomous System 5 - 12.8.7.0/24 51960 0.6% AS14593 -- BRAND-INSTITUTE - Brand Instiute, Inc. 6 - 210.210.112.0/24 48805 0.6% AS9583 -- SIFY-AS-IN Sify Limited 7 - 221.135.80.0/24 48067 0.5% AS9583 -- SIFY-AS-IN Sify Limited 8 - 221.135.251.0/24 42804 0.5% AS9583 -- SIFY-AS-IN Sify Limited 9 - 12.18.36.0/24 39310 0.4% AS11971 -- PFIZERNET-GROTON - PFIZER INC. 10 - 129.80.0.0/16 30747 0.3% AS4184 -- STORTEK-WHQ - Storage Technology Corporation 11 - 199.117.144.0/22 30313 0.3% AS4184 -- STORTEK-WHQ - Storage Technology Corporation 12 - 83.228.71.0/24 28667 0.3% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 13 - 221.128.192.0/18 28275 0.3% AS18231 -- EXATT-AS-AP IOL NETCOM LTD 14 - 72.50.96.0/20 24678 0.3% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 15 - 196.42.0.0/20 23694 0.3% AS10396 -- COQUI-NET - DATACOM CARIBE, INC. 16 - 89.38.98.0/23 15960 0.2% AS6663 -- EUROWEBRO Euroweb Romania SA 17 - 193.93.148.0/22 14927 0.2% AS8266 -- NEXUSTEL Nexus Telecommunications 18 - 86.105.182.0/24 13984 0.2% AS6663 -- EUROWEBRO Euroweb Romania SA 19 - 89.4.131.0/24 13145 0.1% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 20 - 196.27.104.0/21 12894 0.1% AS30969 -- TAN-NET TransAfrica Networks 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 fboronat at dcom.upv.es Fri Sep 26 07:00:19 2008 From: fboronat at dcom.upv.es (=?ISO-8859-1?Q?Fernando_Boronat_Segu=ED?=) Date: Fri, 26 Sep 2008 14:00:19 +0200 Subject: INTENSIVE09 Call for Papers Message-ID: <48DCCED3.1090706@dcom.upv.es> -------------------------------------------- INVITATION ================= Please consider to contribute to and/or forward to the appropriate groups the following opportunity to submit and publish original scientific results. ================= ============== INTENSIVE 2009 | Call for Papers =============== CALL FOR PAPERS, TUTORIALS, PANELS INTENSIVE 2009, The First International Conference on Intensive Applications and Services April 21-25, 2009 - Valencia, Spain General page: http://www.iaria.org/conferences2009/INTENSIVE09.html Call for Papers: http://www.iaria.org/conferences2009/CfPINTENSIVE09.html Submission deadline: November 1, 2008 Submissions will be peer-reviewed, published by IEEE CPS, posted in IEEE Digital Library, and indexed with the major indexes. Extended versions of selected papers will be published in IARIA Journals: http://www.iariajournals.org Please note the Poster Forum special submission with on progress and challenging ideas. INTENSIVE 2009 Special Areas (details in the CfP on site): Basics on IAS (Intensive Applications and Services) ||* *Fundamentals on IAS; Heuristics for relaxing IAS; Optimization on IAS; Coordinated checkpointing and rollback in IAS; Approximation approach in IAS; Suboptimal solutions in IAS; Distribution IAS; Pervasive parallelism IAS Communications intensive || Transaction IAS; Bandwidth IAS; Traffic IAS; Broadcast and multicast IAS; Propagation IAS Process intensive || Resource IAS; Computation IAS; Memory IAS; Data acquisition IAS; Data compression IAS; Replication intensive IAS; Storage IAS; Access IAS; Image processing IAS Operational intensive || Cryptography IAS; Intrusion prevention IAS; Reconfiguration IAS; Load-balancing IAS; Buffering & cashing IAS; Performance IAS User intensive|| User interaction IAS; Multi-user IAS; User-adaptation IAS Technology intensive|| Mobility IAS; High-speed IAS; Intensive real-time decoding Control intensive|| Message IAS; Monitoring IAS; Power IAS; Hardware for IAS; Software for IAS; Middleware for IAS Complex IAS || Bioinformatics computation; Large scale ehealth systems; Pharmaceutical/drug computation; Weather forecast computation; Earthquake simulations; Geo-spatial simulations; Spatial programs; Real-time manufacturing systems; Transportation systems; Avionic systems; Economic/financial systems; Electric-power systems; ========================== *INTENSIVE Advisory Chairs *Petre Dini, Cisco Systems, Inc., USA / Concordia University, Canada Chih-Cheng Hung, Southern Polytechnic State University, USA Jaime Lloret Mauri, Polytechnic University of Valencia, Spain Jianhua Ma, Hosei University, Japan Simon Tsang, Telcordia Technologies, Inc. -- Piscataway, USA *INTENSIVE 2009 General Chair *Fernando Boronat, Integrated Management Coastal Research Institute, Spain *INTENSIVE 2009 Technical Program Committee Chairs *Milena Radenkovic, University of Nottingham, UK Hai Jin, Huazhong University of Science and Technology - Wuhan, China DJamel H. Sadok, Universidade Federal de Pernambuco, Brazil Chieh-Yih Wan, Intel, USA ========================== ============================================================ Dr. Fernando Boronat Segu? Dept. Comunicaciones Tlf.-+34+962 849 300 Ext.-49341 Tlf. directo -+34+962 849 341 Fax.-+34+962 849 309 (Compartido) UNIVERSIDAD POLIT?CNICA DE VALENCIA-Esc. Polit?cnica Superior de Gandia Ctra. Nazaret Oliva, S/N,C.P. 46730, Grao de Gandia (Valencia), SPAIN ============================================================ From cidr-report at potaroo.net Fri Sep 26 07:00:00 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 26 Sep 2008 22:00:00 +1000 (EST) Subject: The Cidr Report Message-ID: <200809261200.m8QC00jg082875@wattle.apnic.net> This report has been generated at Fri Sep 26 21:17:13 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 19-09-08 281956 172041 20-09-08 281868 172074 21-09-08 281827 172189 22-09-08 281819 172625 23-09-08 281367 173268 24-09-08 281992 173902 25-09-08 282130 173067 26-09-08 282212 171940 AS Summary 29495 Number of ASes in routing system 12509 Number of ASes announcing only one prefix 5018 Largest number of prefixes announced by an AS AS4538 : ERX-CERNET-BKB China Education and Research Network Center 88406272 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'). --- 26Sep08 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 282143 172778 109365 38.8% All ASes AS4538 5018 876 4142 82.5% ERX-CERNET-BKB China Education and Research Network Center AS6389 4295 351 3944 91.8% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS209 2957 1348 1609 54.4% ASN-QWEST - Qwest AS1785 1659 159 1500 90.4% AS-PAETEC-NET - PaeTec Communications, Inc. AS4755 1646 299 1347 81.8% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS6298 1998 732 1266 63.4% COX-PHX - Cox Communications Inc. AS17488 1388 300 1088 78.4% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4323 1518 502 1016 66.9% TWTC - tw telecom holdings, inc. AS22773 987 69 918 93.0% CCINET-2 - Cox Communications Inc. AS8151 1410 576 834 59.1% Uninet S.A. de C.V. AS18566 1052 231 821 78.0% COVAD - Covad Communications Co. AS19262 953 228 725 76.1% VZGNI-TRANSIT - Verizon Internet Services Inc. AS11492 1210 487 723 59.8% CABLEONE - CABLE ONE AS2386 1556 910 646 41.5% INS-AS - AT&T Data Communications Services AS9498 680 72 608 89.4% BBIL-AP BHARTI Airtel Ltd. AS6478 1187 587 600 50.5% ATT-INTERNET3 - AT&T WorldNet Services AS18101 776 233 543 70.0% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS3356 1029 527 502 48.8% LEVEL3 Level 3 Communications AS4766 903 416 487 53.9% KIXS-AS-KR Korea Telecom AS4808 626 152 474 75.7% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS17676 524 64 460 87.8% GIGAINFRA BB TECHNOLOGY Corp. AS7029 538 91 447 83.1% WINDSTREAM - Windstream Communications Inc AS855 595 157 438 73.6% CANET-ASN-4 - Bell Aliant AS4134 840 402 438 52.1% CHINANET-BACKBONE No.31,Jin-rong Street AS7545 586 149 437 74.6% TPG-INTERNET-AP TPG Internet Pty Ltd AS9443 523 86 437 83.6% INTERNETPRIMUS-AS-AP Primus Telecommunications AS22047 564 127 437 77.5% VTR BANDA ANCHA S.A. AS7011 913 478 435 47.6% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS7018 1429 997 432 30.2% ATT-INTERNET4 - AT&T WorldNet Services AS24560 586 156 430 73.4% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services Total 39946 11762 28184 70.6% Top 30 total Possible Bogus Routes 24.75.116.0/22 AS10796 SCRR-10796 - Road Runner HoldCo LLC 24.75.160.0/19 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.245.128.0/17 AS11492 CABLEONE - CABLE ONE 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.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.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.79.88.0/24 AS26096 LODDEN - Lodden Services 64.79.89.0/24 AS26096 LODDEN - Lodden Services 64.188.0.0/16 AS3356 LEVEL3 Level 3 Communications 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.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 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 75.101.64.0/20 AS7065 SONOMA - Sonoma Interconnect 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 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 91.208.229.0/24 AS44953 ISICONNEXION IsiConneXion Network 94.158.64.0/20 AS47990 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 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.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.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.248.0/23 AS680 DFN-IP service G-WiN 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.25.240.0/21 AS3209 Arcor IP-Network 193.25.246.0/24 AS3211 Arcor Data-Network 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 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 - 754th Electronic Systems Group 199.114.156.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 199.114.160.0/24 AS1733 CENTAF-SWA - 754th Electronic Systems Group 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.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.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.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.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.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.144.160.0/20 AS7296 ALCHEMYNET - Alchemy Communications, 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.220/32 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.241.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 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/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.74.96.0/19 AS10912 INTERNAP-BLK - Internap Network Services Corporation 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 212.75.192.0/19 AS39927 ELIGHT-AS E-Light-Telecom 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.210.86.0/24 AS577 BACOM - Bell Canada 216.229.51.0/24 AS15211 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 LarrySheldon at cox.net Fri Sep 26 07:45:43 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Fri, 26 Sep 2008 07:45:43 -0500 Subject: breadcrumbs and collusion In-Reply-To: References: Message-ID: <48DCD977.2090807@cox.net> michael.dillon at bt.com wrote: >> However, it makes little sense to close your gate to keep >> the stray dogs out of your yard, if they can just come in via >> your neighbour's gate and climb over the fences. > > It makes a lot of sense. Having closed your gate, and discovered > a stray dog in your back yard, you can call the animal control > people and they stand a good chance of catching that stray dog. Like most NANAE ...eerrr...NANOG metaphors this one is broken. We are not talking about stray dogs, were are talking about bad behaviour. If I keep them from dealing that stuff in my parking lot I do several things, in approximate priority order: My clean customers don't have to suffer any effects of the bad guys being on my lot. The bad guys learn it is not a good place to try to deal. The Law knows one place they don't have to worry about. From trelane at trelane.net Fri Sep 26 08:07:12 2008 From: trelane at trelane.net (Andrew D Kirch) Date: Fri, 26 Sep 2008 09:07:12 -0400 Subject: DDoS from theplanet.com In-Reply-To: References: <20080925230127.6ADDE10BDD2@mx0.northnet.net.nz> Message-ID: <48DCDE80.2020802@trelane.net> Gadi Evron wrote: > On Fri, 26 Sep 2008, Term wrote: >> Hi, >> >> Is there anyone on this list that can give me a noc/security contact >> for someone at theplanet.com >> >> I have been getting a DDos from servers hosted with them for the past >> 60 hours >> and they seem to have the care factor of 0 > > There are some good security people there in recent years, I am sure > they are on it now. > > What contact did you use to try and reach them? Yeah right? Why use a contact and act responsibly when you can simply b***h on NANOG? I know several abuse roles at The Planet, and they aren't hard to get ahold of if you e-mail, or call with the correct information to get the attack stopped. Andrew From jabley at hopcount.ca Fri Sep 26 08:42:10 2008 From: jabley at hopcount.ca (Joe Abley) Date: Fri, 26 Sep 2008 09:42:10 -0400 Subject: ARIN Routing Registry vs RADB vs X In-Reply-To: <3FEEC5BE16966148B912DEB0FF34C81C7B2249@BE09.exg4.exghost.com> References: <3FEEC5BE16966148B912DEB0FF34C81C7B2246@BE09.exg4.exghost.com> <3FEEC5BE16966148B912DEB0FF34C81C7B2249@BE09.exg4.exghost.com> Message-ID: On 25 Sep 2008, at 18:55, Craig Holland wrote: > ...ones that only originate from RADB. This is the part that I found > strange considering the ARIN records are in (show up in) RADB and they > are what most would consider a trusted source. The only RPSL repository that I know of that has any semblance of trustworthiness is the RIPE db, and then, only for resources that were assigned or allocated by the RIPE NCC. The ARIN RR contains just as much cruft as any of the other non-RIPE registries, in my experience. The RADB is nothing special in this regard. Filtering objects with source RPSL and discarding those with source elsewhere is surely all fail and no win. Sounds like someone needs a beating from the cluestick. Joe From tme at multicasttech.com Fri Sep 26 09:04:59 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 26 Sep 2008 10:04:59 -0400 Subject: Internet Filtering Lobby ? Message-ID: Does anyone know what this group is really about and how it might actually impact real networks ? Regards Marshall http://www.artsandlabs.com/ http://blog.wired.com/27bstroke6/2008/09/entertainment-l.html Behind the lobby are AT&T, Cisco Systems, Microsoft, NBC Universal, Viacom and the Songwriters Guild of America. Among other things, the lobby, calledArts+Labs, says "network operators must have the flexibility to manage and expand their networks to defend against net pollution and illegal file-trafficking which threatens to congest and delay the network for all consumers." From ge at linuxbox.org Fri Sep 26 09:08:35 2008 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 26 Sep 2008 09:08:35 -0500 (CDT) Subject: Estonian Cyber Security Strategy document -- now available online Message-ID: Hello. The Estonian cyber security strategy document is now available online. I must say once again the concept of a national cyber security stance is quite interesting. I decided to send a message to NANOG as the "fields of activity" part of the document clearly mentions ISPs in relation to national security and infrastructure: " 12 The growing number of Internet services means that the dependence of our daily activities and lifestyle on the security and proper functioning of information technology increases incessantly. The Internet is an important element of Estonia's critical information infrastructure: it is used daily by the majority of Estonian enterprises and state agencies as well as by more than half the population. The key components of Estonia???s critical information infrastructure, which constitute the IT infrastructure used by enterprises and agencies in the provision of e- services, include: Internet service providers, the name servers of the state, Estonia's root domain, network nodes, service servers and the firewalls of public and private organisations. The seamless operation of this infrastructure is vital to the daily functioning of the Estonian economy." Those who wish to download the document: http://www.mod.gov.ee/?op=body&id=518 My contact there specified she'd be happy to answer any questions. To avoid spam of her inbox, email me for her address. Gadi Evron. From ge at linuxbox.org Fri Sep 26 09:12:30 2008 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 26 Sep 2008 09:12:30 -0500 (CDT) Subject: Internet Filtering Lobby ? In-Reply-To: References: Message-ID: On Fri, 26 Sep 2008, Marshall Eubanks wrote: > Does anyone know what this group is really about and how it might actually > impact real networks ? Reminds me of something Fergie said at ISOI 5 just a couple of weeks ago: if only the records industry was interested in folks like Atrivo and RBN (as they would be doing warez). Oh wait! This seems more like a copyright (and similar) issues group, which wants to filter valid user content (illegal or not) rather than abusive content which damages the net's daily operations. Right. Gadi. > Regards > Marshall > > http://www.artsandlabs.com/ > http://blog.wired.com/27bstroke6/2008/09/entertainment-l.html > > Behind the lobby are AT&T, Cisco Systems, Microsoft, NBC Universal, Viacom > and the Songwriters Guild of America. Among other things, the lobby, > calledArts+Labs, says "network operators must have the flexibility to manage > and expand their networks to defend against net pollution and illegal > file-trafficking which threatens to congest and delay the network for all > consumers." > > > From r.engehausen at gmail.com Fri Sep 26 09:31:14 2008 From: r.engehausen at gmail.com (Roy) Date: Fri, 26 Sep 2008 07:31:14 -0700 Subject: breadcrumbs and collusion In-Reply-To: <48DCD977.2090807@cox.net> References: <48DCD977.2090807@cox.net> Message-ID: <48DCF232.5040103@gmail.com> Let me offer a what might be a better story Joe owns a store where he buys widgets wholesale and sells them retail. A bunch of widget companies get together and pressure the rest of the widget companies not to sell to Joe. Joe finds a lawyer and sues them all for anti-trust violations. Years go by. The companies finally settle for a few bucks with Joe without admitting guilt. The lawyers get rich. From charles at thewybles.com Fri Sep 26 09:49:36 2008 From: charles at thewybles.com (Charles Wyble) Date: Fri, 26 Sep 2008 07:49:36 -0700 Subject: Rackmount Vendors In-Reply-To: References: <48DC7278.9000103@sandboxitsolutions.com> Message-ID: <48DCF680.2000105@thewybles.com> I second that. Worked at several places that used them. Also check out Graybar. They have a will call office in Van Nuys. http://www.graybar.com/ PDU search results for example: http://tinyurl.com/4xh4wg Hope that helps. Steve Pirk wrote: > Not to plug people I know, but Chatsworth Products Inc. > I know they are the best in the area and supply lots of fairly > large cusomers (my real job included). > > http://www.chatsworth.com/datacenter > > -- > Steve > Equal bytes for women. > > On Thu, 25 Sep 2008, Israel Lopez wrote: > >> Hey there, >> >> Anyone know of a good rackmount supplies vendor near the greater Los >> Angeles, CA area? Looking for a rack and some rackmount power strips if >> possible. >> >> Contact me off list. >> >> Thanks Much, >> >> Israel >> > -- Charles Wyble (818) 280 - 7059 http://charlesnw.blogspot.com CTO Known Element Enterprises / SoCal WiFI project From jgreco at ns.sol.net Fri Sep 26 10:31:45 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 26 Sep 2008 10:31:45 -0500 (CDT) Subject: once again, network hardware vendors spamming... In-Reply-To: <9D2F7191-F08B-4C74-81D9-D3CD32AFB6C7@multicasttech.com> from "Marshall Eubanks" at Sep 26, 2008 07:48:21 AM Message-ID: <200809261531.m8QFVjHx055092@aurora.sol.net> > Now, I know you, but there are way too many people on this list to > know them all, or for them to all know you (or me, or anyone else). This caused me to go "aha" and I counted up unique accesses to the URL of the rack diagram I posted yesterday, and came up with 185. Assuming that most people aren't using clients that automatically display URL's in non-HTML e-mail, and that power strip configurations within a rack is a topic of interest to a small subset of subscribers, it seems apparent that there are probably thousands of people reading NANOG traffic on at least a daily basis. It is often easy to forget how many people you're sending to when you're sending to a mailing 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 rsk at gsp.org Fri Sep 26 10:42:19 2008 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 26 Sep 2008 11:42:19 -0400 Subject: Internet Filtering Lobby ? In-Reply-To: References: Message-ID: <20080926154219.GA15591@gsp.org> On Fri, Sep 26, 2008 at 10:04:59AM -0400, Marshall Eubanks wrote: > Does anyone know what this group is really about and how it might > actually impact real networks ? I think Mike Masnick (over at TechDirt) has this nailed: http://www.techdirt.com/articles/20080925/0216422370.shtml Quoting in part: To begin with, the group appears to be positioning "piracy" as something similar to "viruses" or "spam," suggesting an equivalency that should lead to widespread use of filtering equipment. Of course, they seem to be missing the fact that piracy isn't about others with nefarious intent trying to harm or scam you -- but about people getting content that they want. But in Mike McCurry's "up is down, down is up" world, piracy is apparently something that consumers themselves need to be protected from: ---Rsk From mike-nanog at tiedyenetworks.com Fri Sep 26 11:04:27 2008 From: mike-nanog at tiedyenetworks.com (mike) Date: Fri, 26 Sep 2008 09:04:27 -0700 Subject: high latency ds3 issue on unloaded line Message-ID: <48DD080B.1070402@tiedyenetworks.com> Hello, I have a ds3 from qwest which has daily issues with insane point-to-point latencies sometimes exceeding 1000ms for hours on end, and which suddenly disappear, and does not appear to correspond with actual measured link utilization (less than 20mbps most days). To make a long investigation short, the problem comes on during the day and then lets up late in the evening. I have tested and examined everything at the ip layer and no it's not high utilization, an ACL, router cpu or bad hardware, no line errors or other issues visible from interface or controller stats. yes I have flushed all hardware, and I have a 7204vxr/npe-400 with this single ds3. The only clue seems to be millions of 'output drops' from qwest's side. And at night I can hit popular ftp mirrors from a directly attached server and observe my interface reporting about %100 utilization combined with my users and customers, so yeah it really is a full line rate ds3. And historically Mrtg always shows around 20mbps or less utilization and it's only smokeping that goes off, usually in the afternoon when the point to point latencies between my router and qwest start heading north, and consistently at that. I also have another in house tool that takes 30 second snapshots of my ds3 interface in order to catch short bursts that would be smoothed out with mrtg's 5 minute average, but during these high latency times there aren't any spikes noted. And for added confusion (or fun!), the latency can start at any utilization level - I've observed it while we were pulling just 12mbps, and I have not had it while we were doing 34mbps, only the time of day seems to be the common factor. Qwest has not been able to identify the issue, only note that - yeah, this really is happening when there is otherwise no real load on the line - and I am certain we have done everything to rule out the ip layer. They have put in a 'request' to move me to another router, but I am not hopeful of a resolution that way as the router we're currently on doesn't appear otherwise to have the problem with any other subscriber. What I want to know, is it possible that the underlaying atm/sonet that carries my ds3 from my facility is somehow oversubscribed or misconfigured? We have an OC12 fiber entrance and this is the only circuit provisioned on it, and in our small tiny town the only other user on the ring with us is comcast (according to the att network engineer who installed this). I don't know enough about atm/sonet to imagine conditions that would cause the issues I am seeing here , but every ip layer tool I have only ever tells me there isn't an ip issue here. I can issue ping from my router directly to the attached qwest router and get > 1000ms and then other times (out of the problem window), I am getting 4ms. If anyone has laughs or beers to offer me, send 'em on cuz I could use both right about now.... Mike- From aaron at wholesaleinternet.net Fri Sep 26 11:28:48 2008 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Fri, 26 Sep 2008 11:28:48 -0500 Subject: high latency ds3 issue on unloaded line In-Reply-To: <48DD080B.1070402@tiedyenetworks.com> References: <48DD080B.1070402@tiedyenetworks.com> Message-ID: <06c401c91ff4$f43e61a0$dcbb24e0$@net> Have you taken some traffic captures to see what kind of traffic's coming through? Could be an infected machine sending lots of small packets from lots of spoofed addresses. I've seen that kind of thing cause issues with older routers before. -----Original Message----- From: mike [mailto:mike-nanog at tiedyenetworks.com] Sent: Friday, September 26, 2008 11:04 AM To: nanog at nanog.org Subject: high latency ds3 issue on unloaded line Hello, I have a ds3 from qwest which has daily issues with insane point-to-point latencies sometimes exceeding 1000ms for hours on end, and which suddenly disappear, and does not appear to correspond with actual measured link utilization (less than 20mbps most days). To make a long investigation short, the problem comes on during the day and then lets up late in the evening. I have tested and examined everything at the ip layer and no it's not high utilization, an ACL, router cpu or bad hardware, no line errors or other issues visible from interface or controller stats. yes I have flushed all hardware, and I have a 7204vxr/npe-400 with this single ds3. The only clue seems to be millions of 'output drops' from qwest's side. And at night I can hit popular ftp mirrors from a directly attached server and observe my interface reporting about %100 utilization combined with my users and customers, so yeah it really is a full line rate ds3. And historically Mrtg always shows around 20mbps or less utilization and it's only smokeping that goes off, usually in the afternoon when the point to point latencies between my router and qwest start heading north, and consistently at that. I also have another in house tool that takes 30 second snapshots of my ds3 interface in order to catch short bursts that would be smoothed out with mrtg's 5 minute average, but during these high latency times there aren't any spikes noted. And for added confusion (or fun!), the latency can start at any utilization level - I've observed it while we were pulling just 12mbps, and I have not had it while we were doing 34mbps, only the time of day seems to be the common factor. Qwest has not been able to identify the issue, only note that - yeah, this really is happening when there is otherwise no real load on the line - and I am certain we have done everything to rule out the ip layer. They have put in a 'request' to move me to another router, but I am not hopeful of a resolution that way as the router we're currently on doesn't appear otherwise to have the problem with any other subscriber. What I want to know, is it possible that the underlaying atm/sonet that carries my ds3 from my facility is somehow oversubscribed or misconfigured? We have an OC12 fiber entrance and this is the only circuit provisioned on it, and in our small tiny town the only other user on the ring with us is comcast (according to the att network engineer who installed this). I don't know enough about atm/sonet to imagine conditions that would cause the issues I am seeing here , but every ip layer tool I have only ever tells me there isn't an ip issue here. I can issue ping from my router directly to the attached qwest router and get > 1000ms and then other times (out of the problem window), I am getting 4ms. If anyone has laughs or beers to offer me, send 'em on cuz I could use both right about now.... Mike- From chip.gwyn at gmail.com Fri Sep 26 12:01:40 2008 From: chip.gwyn at gmail.com (chip) Date: Fri, 26 Sep 2008 13:01:40 -0400 Subject: high latency ds3 issue on unloaded line In-Reply-To: <06c401c91ff4$f43e61a0$dcbb24e0$@net> References: <48DD080B.1070402@tiedyenetworks.com> <06c401c91ff4$f43e61a0$dcbb24e0$@net> Message-ID: <64a8ad980809261001o631faf87r6a88354f2f6c1a7@mail.gmail.com> Mike, I've seen issues similar to this when using the 12 Port DS3 cards, Engine O, in Cisco GSR's. Basically if there's any single ds3 that is full on any of the 12 ports, then the buffers on the card fill up and every other port on that card has their traffic queued, thus introducing latency. There are some things that can be done to help with the situation but not much to actually resolve the issue. One is to use WRED instead of FIFO on the ints at the provider side. A more effective solution, but more invasive, is to basically set each card's tx queue to 1 so when something is waiting on the blocked port, packets are dropped instead of queued. Applied Globally: cos-queue-group 1-16 precedence all random-detect-label 0 random-detect-label 0 1 16 1 Ints w/less than 45Mb tx-cos 1-16 tx-queue-limit 1 Mostly this is just done on the interfaces that are configured with a clock rate less than 45Mb. Of course, all this will need to be done on the Qwest side. Since you're only see this issue during the day, it points to a traffic problem. If qwest needs some proof have them run this command when you're seeing the high latency: execute-on slot show contro frfab queue execute-on slot show contro tofab queue That is, if they're using those cards on a GSR. Hope that helps. --chip On Fri, Sep 26, 2008 at 12:28 PM, Aaron Wendel wrote: > Have you taken some traffic captures to see what kind of traffic's coming > through? Could be an infected machine sending lots of small packets from > lots of spoofed addresses. I've seen that kind of thing cause issues with > older routers before. > > > > -----Original Message----- > From: mike [mailto:mike-nanog at tiedyenetworks.com] > Sent: Friday, September 26, 2008 11:04 AM > To: nanog at nanog.org > Subject: high latency ds3 issue on unloaded line > > Hello, > > I have a ds3 from qwest which has daily issues with insane > point-to-point latencies sometimes exceeding 1000ms for hours on end, > and which suddenly disappear, and does not appear to correspond with > actual measured link utilization (less than 20mbps most days). > > To make a long investigation short, the problem comes on during the > day and then lets up late in the evening. I have tested and examined > everything at the ip layer and no it's not high utilization, an ACL, > router cpu or bad hardware, no line errors or other issues visible from > interface or controller stats. yes I have flushed all hardware, and I > have a 7204vxr/npe-400 with this single ds3. The only clue seems to be > millions of 'output drops' from qwest's side. And at night I can hit > popular ftp mirrors from a directly attached server and observe my > interface reporting about %100 utilization combined with my users and > customers, so yeah it really is a full line rate ds3. And historically > Mrtg always shows around 20mbps or less utilization and it's only > smokeping that goes off, usually in the afternoon when the point to > point latencies between my router and qwest start heading north, and > consistently at that. I also have another in house tool that takes 30 > second snapshots of my ds3 interface in order to catch short bursts that > would be smoothed out with mrtg's 5 minute average, but during these > high latency times there aren't any spikes noted. And for added > confusion (or fun!), the latency can start at any utilization level - > I've observed it while we were pulling just 12mbps, and I have not had > it while we were doing 34mbps, only the time of day seems to be the > common factor. > > Qwest has not been able to identify the issue, only note that - > yeah, this really is happening when there is otherwise no real load on > the line - and I am certain we have done everything to rule out the ip > layer. They have put in a 'request' to move me to another router, but I > am not hopeful of a resolution that way as the router we're currently on > doesn't appear otherwise to have the problem with any other subscriber. > > What I want to know, is it possible that the underlaying atm/sonet > that carries my ds3 from my facility is somehow oversubscribed or > misconfigured? We have an OC12 fiber entrance and this is the only > circuit provisioned on it, and in our small tiny town the only other > user on the ring with us is comcast (according to the att network > engineer who installed this). I don't know enough about atm/sonet to > imagine conditions that would cause the issues I am seeing here , but > every ip layer tool I have only ever tells me there isn't an ip issue > here. I can issue ping from my router directly to the attached qwest > router and get > 1000ms and then other times (out of the problem > window), I am getting 4ms. > > If anyone has laughs or beers to offer me, send 'em on cuz I could > use both right about now.... > > Mike- > > > > > > -- Just my $.02, your mileage may vary, batteries not included, etc.... From cscora at apnic.net Fri Sep 26 13:09:23 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 27 Sep 2008 04:09:23 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200809261809.m8QI9NbX030344@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 27 Sep, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 269646 Prefixes after maximum aggregation: 130166 Deaggregation factor: 2.07 Unique aggregates announced to Internet: 131386 Total ASes present in the Internet Routing Table: 29358 Prefixes per ASN: 9.18 Origin-only ASes present in the Internet Routing Table: 25526 Origin ASes announcing only one prefix: 12442 Transit ASes present in the Internet Routing Table: 3832 Transit-only ASes present in the Internet Routing Table: 87 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 26 Max AS path prepend of ASN ( 3816) 15 Prefixes from unregistered ASNs in the Routing Table: 561 Unregistered ASNs in the Routing Table: 205 Number of 32-bit ASNs allocated by the RIRs: 60 Prefixes from 32-bit ASNs in the Routing Table: 9 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 750 Number of addresses announced to Internet: 1908123392 Equivalent to 113 /8s, 187 /16s and 167 /24s Percentage of available address space announced: 51.5 Percentage of allocated address space announced: 62.5 Percentage of available address space allocated: 82.3 Percentage of address space in use by end-sites: 73.6 Total number of prefixes smaller than registry allocations: 132238 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 62392 Total APNIC prefixes after maximum aggregation: 23007 APNIC Deaggregation factor: 2.71 Prefixes being announced from the APNIC address blocks: 59284 Unique aggregates announced from the APNIC address blocks: 26672 APNIC Region origin ASes present in the Internet Routing Table: 3394 APNIC Prefixes per ASN: 17.47 APNIC Region origin ASes announcing only one prefix: 911 APNIC Region transit ASes present in the Internet Routing Table: 540 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 19 Number of APNIC addresses announced to Internet: 377913312 Equivalent to 22 /8s, 134 /16s and 127 /24s Percentage of available APNIC address space announced: 80.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: 122559 Total ARIN prefixes after maximum aggregation: 64697 ARIN Deaggregation factor: 1.89 Prefixes being announced from the ARIN address blocks: 91822 Unique aggregates announced from the ARIN address blocks: 35181 ARIN Region origin ASes present in the Internet Routing Table: 12484 ARIN Prefixes per ASN: 7.36 ARIN Region origin ASes announcing only one prefix: 4833 ARIN Region transit ASes present in the Internet Routing Table: 1194 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 16 Number of ARIN addresses announced to Internet: 364411872 Equivalent to 21 /8s, 184 /16s and 123 /24s Percentage of available ARIN address space announced: 74.9 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: 58577 Total RIPE prefixes after maximum aggregation: 35374 RIPE Deaggregation factor: 1.66 Prefixes being announced from the RIPE address blocks: 53728 Unique aggregates announced from the RIPE address blocks: 35985 RIPE Region origin ASes present in the Internet Routing Table: 11935 RIPE Prefixes per ASN: 4.50 RIPE Region origin ASes announcing only one prefix: 6284 RIPE Region transit ASes present in the Internet Routing Table: 1823 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 26 Number of RIPE addresses announced to Internet: 373446752 Equivalent to 22 /8s, 66 /16s and 88 /24s Percentage of available RIPE address space announced: 85.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-49151 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: 21455 Total LACNIC prefixes after maximum aggregation: 5370 LACNIC Deaggregation factor: 4.00 Prefixes being announced from the LACNIC address blocks: 19570 Unique aggregates announced from the LACNIC address blocks: 11038 LACNIC Region origin ASes present in the Internet Routing Table: 1002 LACNIC Prefixes per ASN: 19.53 LACNIC Region origin ASes announcing only one prefix: 330 LACNIC Region transit ASes present in the Internet Routing Table: 170 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 17 Number of LACNIC addresses announced to Internet: 56803328 Equivalent to 3 /8s, 98 /16s and 192 /24s Percentage of available LACNIC address space announced: 56.4 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: 4103 Total AfriNIC prefixes after maximum aggregation: 1272 AfriNIC Deaggregation factor: 3.23 Prefixes being announced from the AfriNIC address blocks: 4412 Unique aggregates announced from the AfriNIC address blocks: 2035 AfriNIC Region origin ASes present in the Internet Routing Table: 260 AfriNIC Prefixes per ASN: 16.97 AfriNIC Region origin ASes announcing only one prefix: 84 AfriNIC Region transit ASes present in the Internet Routing Table: 53 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 13 Number of AfriNIC addresses announced to Internet: 12755200 Equivalent to 0 /8s, 194 /16s and 161 /24s Percentage of available AfriNIC address space announced: 38.0 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 1639 535 179 TATA Communications formerly 17488 1392 94 101 Hathway IP Over Cable Interne 9583 1109 86 475 Sify Limited 4766 876 6407 359 Korea Telecom (KIX) 4134 839 13665 343 CHINANET-BACKBONE 23577 811 34 691 Korea Telecom (ATM-MPLS) 18101 776 161 62 Reliance Infocom Ltd Internet 4780 717 353 61 Digital United Inc. 9498 679 295 56 BHARTI BT INTERNET LTD. 4808 626 1156 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 4293 3416 339 bellsouth.net, inc. 209 2942 4017 621 Qwest 6298 1997 318 731 Cox Communicatons 20115 1682 1421 712 Charter Communications 1785 1663 717 154 PaeTec Communications, Inc. 2386 1551 691 894 AT&T Data Communications Serv 4323 1519 1067 369 Time Warner Telecom 7018 1408 5794 978 AT&T WorldNet Services 11492 1212 152 11 Cable One 6478 1188 241 189 AT&T Worldnet Services 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 423 1777 378 TDC Tele Danmark 3301 330 1428 301 TeliaNet Sweden 30890 330 87 175 SC Kappa Invexim SRL 3215 328 2756 107 France Telecom Transpac 3320 324 7063 273 Deutsche Telekom AG 8866 321 79 22 Bulgarian Telecommunication C 8452 316 188 11 TEDATA 5462 299 794 26 Telewest Broadband 8551 287 270 37 Bezeq International 680 275 2047 265 DFN-IP service G-WiN 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 1412 2847 223 UniNet S.A. de C.V. 11830 668 299 9 Instituto Costarricense de El 22047 564 270 14 VTR PUNTO NET S.A. 7303 492 241 70 Telecom Argentina Stet-France 10620 433 106 62 TVCABLE BOGOTA 16814 426 27 10 NSS, S.A. 6471 420 85 48 ENTEL CHILE S.A. 11172 408 118 71 Servicios Alestra S.A de C.V 28573 351 444 22 NET Servicos de Comunicao S.A 14117 343 23 9 Telefonica del Sur S.A. 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 543 71 41 LINKdotNET AS number 20858 401 34 3 EgyNet 3741 265 855 223 The Internet Solution 2018 232 215 139 Tertiary Education Network 6713 143 135 11 Itissalat Al-MAGHRIB 5536 120 8 17 Internet Egypt Network 5713 119 555 69 Telkom SA Ltd 33776 116 6 3 Starcomms Nigeria Limited 29571 107 13 8 Ci Telecom Autonomous system 33783 91 10 9 EEPAD TISP TELECOM & INTERNET 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 4293 3416 339 bellsouth.net, inc. 209 2942 4017 621 Qwest 6298 1997 318 731 Cox Communicatons 20115 1682 1421 712 Charter Communications 1785 1663 717 154 PaeTec Communications, Inc. 4755 1639 535 179 TATA Communications formerly 2386 1551 691 894 AT&T Data Communications Serv 4323 1519 1067 369 Time Warner Telecom 8151 1412 2847 223 UniNet S.A. de C.V. 7018 1408 5794 978 AT&T WorldNet Services Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 209 2942 2321 Qwest 1785 1663 1509 PaeTec Communications, Inc. 4755 1639 1460 TATA Communications formerly 17488 1392 1291 Hathway IP Over Cable Interne 6298 1997 1266 Cox Communicatons 11492 1212 1201 Cable One 8151 1412 1189 UniNet S.A. de C.V. 4323 1519 1150 Time Warner Telecom 18566 1052 1042 Covad Communications 6478 1188 999 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 7018 AT&T WorldNet Servic 22492 UNALLOCATED 12.2.46.0/24 1239 Sprint 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 32326 UNALLOCATED 12.40.49.0/24 3549 Global Crossing Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.75.116.0/22 10796 ServiceCo LLC - Road Runner 24.75.160.0/19 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 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio 63.143.71.0/24 701 UUNET Technologies, Inc. 63.143.115.0/24 701 UUNET Technologies, Inc. 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:17 /11:45 /12:147 /13:295 /14:530 /15:1062 /16:10110 /17:4400 /18:7671 /19:16306 /20:19136 /21:18667 /22:23430 /23:24514 /24:140652 /25:797 /26:967 /27:767 /28:89 /29:9 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2845 4293 bellsouth.net, inc. 6298 1971 1997 Cox Communicatons 209 1702 2942 Qwest 2386 1231 1551 AT&T Data Communications Serv 17488 1199 1392 Hathway IP Over Cable Interne 11492 1188 1212 Cable One 1785 1126 1663 PaeTec Communications, Inc. 6478 1080 1188 AT&T Worldnet Services 18566 1033 1052 Covad Communications 9583 977 1109 Sify Limited Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:8 8:139 12:2163 13:2 15:22 16:3 17:5 18:13 20:35 24:1080 32:59 38:501 40:92 41:703 43:1 44:2 47:12 52:3 55:3 56:3 57:27 58:521 59:521 60:452 61:975 62:1226 63:2035 64:3218 65:2388 66:3485 67:1262 68:790 69:2328 70:853 71:172 72:2053 73:7 74:1199 75:166 76:264 77:795 78:840 79:258 80:939 81:838 82:583 83:377 84:576 85:1003 86:398 87:717 88:338 89:1361 90:21 91:1535 92:267 93:851 94:178 96:74 97:81 98:335 99:8 113:1 114:110 115:86 116:1001 117:366 118:232 119:498 120:94 121:597 122:850 123:437 124:862 125:1196 128:358 129:201 130:134 131:413 132:70 133:9 134:177 135:32 136:224 137:96 138:142 139:91 140:507 141:103 142:408 143:302 144:326 145:51 146:370 147:159 148:521 149:209 150:128 151:181 152:149 153:136 154:10 155:281 156:173 157:301 158:168 159:306 160:268 161:138 162:254 163:154 164:516 165:503 166:367 167:332 168:634 169:143 170:447 171:33 172:10 173:34 186:1 187:16 188:1 189:312 190:2226 192:5756 193:4136 194:3256 195:2583 196:997 198:3727 199:3301 200:5508 201:1436 202:7853 203:8086 204:3949 205:2140 206:2351 207:2739 208:3643 209:3420 210:2613 211:1088 212:1466 213:1631 214:176 215:50 216:4354 217:1218 218:350 219:437 220:1064 221:418 222:287 End of report From justin at justinshore.com Fri Sep 26 13:16:21 2008 From: justin at justinshore.com (Justin Shore) Date: Fri, 26 Sep 2008 13:16:21 -0500 Subject: L3 route flapping Message-ID: <48DD26F5.3040405@justinshore.com> Is anyone else seeing 72.237.248.0/22 flapping? As of about 10 minutes ago Oregon-IX reported that it had flapped 8 times in 50 minutes. We have a production phone system on that network that's going crazy. Thanks Justin From prue at usc.edu Fri Sep 26 13:31:50 2008 From: prue at usc.edu (prue) Date: Fri, 26 Sep 2008 11:31:50 -0700 (PDT) Subject: high latency ds3 issue on unloaded line Message-ID: <0K7T006WKFH0KK10@msg-scanner2.usc.edu> I am wondering if the packets might be MD5 packets addressed to your router. They might be small with no valid content but your router gets busy validating the MD5 sum for each packet before the router then drops the packet. That keeps the router busy doing nothing useful. Did you check your CPU utilization during the high latency periods then check to see which process is consuming the CPU cycles if it does look high? Walt From john at internetassociatesllc.com Fri Sep 26 13:59:12 2008 From: john at internetassociatesllc.com (John Lee) Date: Fri, 26 Sep 2008 13:59:12 -0500 Subject: high latency ds3 issue on unloaded line In-Reply-To: <48DD080B.1070402@tiedyenetworks.com> References: <48DD080B.1070402@tiedyenetworks.com> Message-ID: <53A6C7E936ED8544B1A2BC990D254F942EA6F76A2B@MEMEXG1.HOST.local> Mike, Your latencies which suddenly appear for several hours and then go away and do this on a regular basis sounds like a layer 2, facility switching issue. As you indicated " the problem comes on during the day and then lets up late in the evening" sounds like the under lying facility is being switched back around the "long side" of the SONET ring or other facility. Some carrier facilities are scheduled for "one path or direction" say during the day that are supposed to be for lower latency time periods for interactive work and then switch for a lower cost, higher latency path in the evening when computer to computer backups do not care. If you can plot the times the issues start and end and that these occur daily during the week and not on weekends etc that would be a strong indicator. John (ISDN) Lee ________________________________________ From: mike [mike-nanog at tiedyenetworks.com] Sent: Friday, September 26, 2008 12:04 PM To: nanog at nanog.org Subject: high latency ds3 issue on unloaded line Hello, I have a ds3 from qwest which has daily issues with insane point-to-point latencies sometimes exceeding 1000ms for hours on end, and which suddenly disappear, and does not appear to correspond with actual measured link utilization (less than 20mbps most days). To make a long investigation short, the problem comes on during the day and then lets up late in the evening. I have tested and examined everything at the ip layer and no it's not high utilization, an ACL, router cpu or bad hardware, no line errors or other issues visible from interface or controller stats. yes I have flushed all hardware, and I have a 7204vxr/npe-400 with this single ds3. The only clue seems to be millions of 'output drops' from qwest's side. And at night I can hit popular ftp mirrors from a directly attached server and observe my interface reporting about %100 utilization combined with my users and customers, so yeah it really is a full line rate ds3. And historically Mrtg always shows around 20mbps or less utilization and it's only smokeping that goes off, usually in the afternoon when the point to point latencies between my router and qwest start heading north, and consistently at that. I also have another in house tool that takes 30 second snapshots of my ds3 interface in order to catch short bursts that would be smoothed out with mrtg's 5 minute average, but during these high latency times there aren't any spikes noted. And for added confusion (or fun!), the latency can start at any utilization level - I've observed it while we were pulling just 12mbps, and I have not had it while we were doing 34mbps, only the time of day seems to be the common factor. Qwest has not been able to identify the issue, only note that - yeah, this really is happening when there is otherwise no real load on the line - and I am certain we have done everything to rule out the ip layer. They have put in a 'request' to move me to another router, but I am not hopeful of a resolution that way as the router we're currently on doesn't appear otherwise to have the problem with any other subscriber. What I want to know, is it possible that the underlaying atm/sonet that carries my ds3 from my facility is somehow oversubscribed or misconfigured? We have an OC12 fiber entrance and this is the only circuit provisioned on it, and in our small tiny town the only other user on the ring with us is comcast (according to the att network engineer who installed this). I don't know enough about atm/sonet to imagine conditions that would cause the issues I am seeing here , but every ip layer tool I have only ever tells me there isn't an ip issue here. I can issue ping from my router directly to the attached qwest router and get > 1000ms and then other times (out of the problem window), I am getting 4ms. If anyone has laughs or beers to offer me, send 'em on cuz I could use both right about now.... Mike- From kris.foster at gmail.com Fri Sep 26 14:17:14 2008 From: kris.foster at gmail.com (kris foster) Date: Fri, 26 Sep 2008 12:17:14 -0700 Subject: high latency ds3 issue on unloaded line In-Reply-To: <53A6C7E936ED8544B1A2BC990D254F942EA6F76A2B@MEMEXG1.HOST.local> References: <48DD080B.1070402@tiedyenetworks.com> <53A6C7E936ED8544B1A2BC990D254F942EA6F76A2B@MEMEXG1.HOST.local> Message-ID: <674C83D1-A652-4F8F-B5B1-0CCED0E616FC@gmail.com> John Even if this is happening, the distance you can travel at 2/3 sol says there is something else going wrong here (1 sec latency is a very long time). Kris On Sep 26, 2008, at 11:59 AM, John Lee wrote: > Mike, > > Your latencies which suddenly appear for several hours and then go > away and do this on a regular basis sounds like a layer 2, facility > switching issue. As you indicated " the problem comes on during the > day and then lets up late in the evening" sounds like the under > lying facility is being switched back around the "long side" of the > SONET ring or other facility. Some carrier facilities are scheduled > for "one path or direction" say during the day that are supposed to > be for lower latency time periods for interactive work and then > switch for a lower cost, higher latency path in the evening when > computer to computer backups do not care. If you can plot the times > the issues start and end and that these occur daily during the week > and not on weekends etc that would be a strong indicator. > > John (ISDN) Lee > > ________________________________________ > From: mike [mike-nanog at tiedyenetworks.com] > Sent: Friday, September 26, 2008 12:04 PM > To: nanog at nanog.org > Subject: high latency ds3 issue on unloaded line > > Hello, > > I have a ds3 from qwest which has daily issues with insane > point-to-point latencies sometimes exceeding 1000ms for hours on end, > and which suddenly disappear, and does not appear to correspond with > actual measured link utilization (less than 20mbps most days). > > To make a long investigation short, the problem comes on during the > day and then lets up late in the evening. I have tested and examined > everything at the ip layer and no it's not high utilization, an ACL, > router cpu or bad hardware, no line errors or other issues visible > from > interface or controller stats. yes I have flushed all hardware, and I > have a 7204vxr/npe-400 with this single ds3. The only clue seems to be > millions of 'output drops' from qwest's side. And at night I can hit > popular ftp mirrors from a directly attached server and observe my > interface reporting about %100 utilization combined with my users and > customers, so yeah it really is a full line rate ds3. And historically > Mrtg always shows around 20mbps or less utilization and it's only > smokeping that goes off, usually in the afternoon when the point to > point latencies between my router and qwest start heading north, and > consistently at that. I also have another in house tool that takes 30 > second snapshots of my ds3 interface in order to catch short bursts > that > would be smoothed out with mrtg's 5 minute average, but during these > high latency times there aren't any spikes noted. And for added > confusion (or fun!), the latency can start at any utilization level - > I've observed it while we were pulling just 12mbps, and I have not had > it while we were doing 34mbps, only the time of day seems to be the > common factor. > > Qwest has not been able to identify the issue, only note that - > yeah, this really is happening when there is otherwise no real load on > the line - and I am certain we have done everything to rule out the ip > layer. They have put in a 'request' to move me to another router, > but I > am not hopeful of a resolution that way as the router we're > currently on > doesn't appear otherwise to have the problem with any other > subscriber. > > What I want to know, is it possible that the underlaying atm/sonet > that carries my ds3 from my facility is somehow oversubscribed or > misconfigured? We have an OC12 fiber entrance and this is the only > circuit provisioned on it, and in our small tiny town the only other > user on the ring with us is comcast (according to the att network > engineer who installed this). I don't know enough about atm/sonet to > imagine conditions that would cause the issues I am seeing here , but > every ip layer tool I have only ever tells me there isn't an ip issue > here. I can issue ping from my router directly to the attached qwest > router and get > 1000ms and then other times (out of the problem > window), I am getting 4ms. > > If anyone has laughs or beers to offer me, send 'em on cuz I could > use both right about now.... > > Mike- > From jay at west.net Fri Sep 26 14:20:24 2008 From: jay at west.net (Jay Hennigan) Date: Fri, 26 Sep 2008 12:20:24 -0700 Subject: high latency ds3 issue on unloaded line In-Reply-To: <53A6C7E936ED8544B1A2BC990D254F942EA6F76A2B@MEMEXG1.HOST.local> References: <48DD080B.1070402@tiedyenetworks.com> <53A6C7E936ED8544B1A2BC990D254F942EA6F76A2B@MEMEXG1.HOST.local> Message-ID: <48DD35F8.7010303@west.net> John Lee wrote: > Mike, > > Your latencies which suddenly appear for several hours and then go away and do this on a regular basis sounds like a layer 2, facility switching issue. As you indicated " the problem comes on during the day and then lets up late in the evening" sounds like the under lying facility is being switched back around the "long side" of the SONET ring or other facility. Some carrier facilities are scheduled for "one path or direction" say during the day that are supposed to be for lower latency time periods for interactive work and then switch for a lower cost, higher latency path in the evening when computer to computer backups do not care. If you can plot the times the issues start and end and that these occur daily during the week and not on weekends etc that would be a strong indicator. For 1000 ms latencies, that would be a VERY long "long side". I think there is something else going on here. -- 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 john at internetassociatesllc.com Fri Sep 26 14:26:32 2008 From: john at internetassociatesllc.com (John Lee) Date: Fri, 26 Sep 2008 14:26:32 -0500 Subject: high latency ds3 issue on unloaded line In-Reply-To: <674C83D1-A652-4F8F-B5B1-0CCED0E616FC@gmail.com> References: <48DD080B.1070402@tiedyenetworks.com> <53A6C7E936ED8544B1A2BC990D254F942EA6F76A2B@MEMEXG1.HOST.local>, <674C83D1-A652-4F8F-B5B1-0CCED0E616FC@gmail.com> Message-ID: <53A6C7E936ED8544B1A2BC990D254F942EA6F76A2C@MEMEXG1.HOST.local> Kris, No disagreement on the sol, the issue is how many oeos the signal is going through and how far it is going. When the facilities switched in a previous life the latencies usually took a several hundred millisecond jump but not seconds. My question / issue is the repeatability and schedule of the lengthening delay and what other activity event would correlate with it. John ________________________________________ From: kris foster [kris.foster at gmail.com] Sent: Friday, September 26, 2008 3:17 PM To: John Lee Cc: mike; nanog at nanog.org Subject: Re: high latency ds3 issue on unloaded line John Even if this is happening, the distance you can travel at 2/3 sol says there is something else going wrong here (1 sec latency is a very long time). Kris On Sep 26, 2008, at 11:59 AM, John Lee wrote: > Mike, > > Your latencies which suddenly appear for several hours and then go > away and do this on a regular basis sounds like a layer 2, facility > switching issue. As you indicated " the problem comes on during the > day and then lets up late in the evening" sounds like the under > lying facility is being switched back around the "long side" of the > SONET ring or other facility. Some carrier facilities are scheduled > for "one path or direction" say during the day that are supposed to > be for lower latency time periods for interactive work and then > switch for a lower cost, higher latency path in the evening when > computer to computer backups do not care. If you can plot the times > the issues start and end and that these occur daily during the week > and not on weekends etc that would be a strong indicator. > > John (ISDN) Lee > > ________________________________________ > From: mike [mike-nanog at tiedyenetworks.com] > Sent: Friday, September 26, 2008 12:04 PM > To: nanog at nanog.org > Subject: high latency ds3 issue on unloaded line > > Hello, > > I have a ds3 from qwest which has daily issues with insane > point-to-point latencies sometimes exceeding 1000ms for hours on end, > and which suddenly disappear, and does not appear to correspond with > actual measured link utilization (less than 20mbps most days). > > To make a long investigation short, the problem comes on during the > day and then lets up late in the evening. I have tested and examined > everything at the ip layer and no it's not high utilization, an ACL, > router cpu or bad hardware, no line errors or other issues visible > from > interface or controller stats. yes I have flushed all hardware, and I > have a 7204vxr/npe-400 with this single ds3. The only clue seems to be > millions of 'output drops' from qwest's side. And at night I can hit > popular ftp mirrors from a directly attached server and observe my > interface reporting about %100 utilization combined with my users and > customers, so yeah it really is a full line rate ds3. And historically > Mrtg always shows around 20mbps or less utilization and it's only > smokeping that goes off, usually in the afternoon when the point to > point latencies between my router and qwest start heading north, and > consistently at that. I also have another in house tool that takes 30 > second snapshots of my ds3 interface in order to catch short bursts > that > would be smoothed out with mrtg's 5 minute average, but during these > high latency times there aren't any spikes noted. And for added > confusion (or fun!), the latency can start at any utilization level - > I've observed it while we were pulling just 12mbps, and I have not had > it while we were doing 34mbps, only the time of day seems to be the > common factor. > > Qwest has not been able to identify the issue, only note that - > yeah, this really is happening when there is otherwise no real load on > the line - and I am certain we have done everything to rule out the ip > layer. They have put in a 'request' to move me to another router, > but I > am not hopeful of a resolution that way as the router we're > currently on > doesn't appear otherwise to have the problem with any other > subscriber. > > What I want to know, is it possible that the underlaying atm/sonet > that carries my ds3 from my facility is somehow oversubscribed or > misconfigured? We have an OC12 fiber entrance and this is the only > circuit provisioned on it, and in our small tiny town the only other > user on the ring with us is comcast (according to the att network > engineer who installed this). I don't know enough about atm/sonet to > imagine conditions that would cause the issues I am seeing here , but > every ip layer tool I have only ever tells me there isn't an ip issue > here. I can issue ping from my router directly to the attached qwest > router and get > 1000ms and then other times (out of the problem > window), I am getting 4ms. > > If anyone has laughs or beers to offer me, send 'em on cuz I could > use both right about now.... > > Mike- > From bplimpton at sopris.net Fri Sep 26 14:35:16 2008 From: bplimpton at sopris.net (Ben Plimpton) Date: Fri, 26 Sep 2008 13:35:16 -0600 Subject: high latency ds3 issue on unloaded line In-Reply-To: <53A6C7E936ED8544B1A2BC990D254F942EA6F76A2B@MEMEXG1.HOST.local> References: <48DD080B.1070402@tiedyenetworks.com> <53A6C7E936ED8544B1A2BC990D254F942EA6F76A2B@MEMEXG1.HOST.local> Message-ID: <50BC6D22-6B75-4F1A-8C39-356FFA8ABD7E@sopris.net> We've had a similar issue with a few of our Qwest DS3's. The solution has been 1 of the following.... 1) Qwest has over-provisioned the transit links on their atm network that the DS3 is riding and the during peak times of the day, the transit link becomes congested causing high latency not related to our traffic levels. So the congestion could be appearing beyond your local loop. 2) We also had an instance where qwest had an issue with the PVC on the atm switch that we connected into that was causing > 500ms of latency. Like you, we are in a small town served by older ATM switches, so you might just see if they can rebuild both sides to see if that clears it up. Sounds quacky, but after 12 hours of troubleshooting, that was the fix. Ben On Sep 26, 2008, at 12:59 PM, John Lee wrote: > Mike, > > Your latencies which suddenly appear for several hours and then go > away and do this on a regular basis sounds like a layer 2, facility > switching issue. As you indicated " the problem comes on during the > day and then lets up late in the evening" sounds like the under > lying facility is being switched back around the "long side" of the > SONET ring or other facility. Some carrier facilities are scheduled > for "one path or direction" say during the day that are supposed to > be for lower latency time periods for interactive work and then > switch for a lower cost, higher latency path in the evening when > computer to computer backups do not care. If you can plot the times > the issues start and end and that these occur daily during the week > and not on weekends etc that would be a strong indicator. > > John (ISDN) Lee > > ________________________________________ > From: mike [mike-nanog at tiedyenetworks.com] > Sent: Friday, September 26, 2008 12:04 PM > To: nanog at nanog.org > Subject: high latency ds3 issue on unloaded line > > Hello, > > I have a ds3 from qwest which has daily issues with insane > point-to-point latencies sometimes exceeding 1000ms for hours on end, > and which suddenly disappear, and does not appear to correspond with > actual measured link utilization (less than 20mbps most days). > > To make a long investigation short, the problem comes on during the > day and then lets up late in the evening. I have tested and examined > everything at the ip layer and no it's not high utilization, an ACL, > router cpu or bad hardware, no line errors or other issues visible > from > interface or controller stats. yes I have flushed all hardware, and I > have a 7204vxr/npe-400 with this single ds3. The only clue seems to be > millions of 'output drops' from qwest's side. And at night I can hit > popular ftp mirrors from a directly attached server and observe my > interface reporting about %100 utilization combined with my users and > customers, so yeah it really is a full line rate ds3. And historically > Mrtg always shows around 20mbps or less utilization and it's only > smokeping that goes off, usually in the afternoon when the point to > point latencies between my router and qwest start heading north, and > consistently at that. I also have another in house tool that takes 30 > second snapshots of my ds3 interface in order to catch short bursts > that > would be smoothed out with mrtg's 5 minute average, but during these > high latency times there aren't any spikes noted. And for added > confusion (or fun!), the latency can start at any utilization level - > I've observed it while we were pulling just 12mbps, and I have not had > it while we were doing 34mbps, only the time of day seems to be the > common factor. > > Qwest has not been able to identify the issue, only note that - > yeah, this really is happening when there is otherwise no real load on > the line - and I am certain we have done everything to rule out the ip > layer. They have put in a 'request' to move me to another router, > but I > am not hopeful of a resolution that way as the router we're > currently on > doesn't appear otherwise to have the problem with any other > subscriber. > > What I want to know, is it possible that the underlaying atm/sonet > that carries my ds3 from my facility is somehow oversubscribed or > misconfigured? We have an OC12 fiber entrance and this is the only > circuit provisioned on it, and in our small tiny town the only other > user on the ring with us is comcast (according to the att network > engineer who installed this). I don't know enough about atm/sonet to > imagine conditions that would cause the issues I am seeing here , but > every ip layer tool I have only ever tells me there isn't an ip issue > here. I can issue ping from my router directly to the attached qwest > router and get > 1000ms and then other times (out of the problem > window), I am getting 4ms. > > If anyone has laughs or beers to offer me, send 'em on cuz I could > use both right about now.... > > Mike- > From morrowc.lists at gmail.com Fri Sep 26 21:13:46 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 26 Sep 2008 22:13:46 -0400 Subject: About.com/NYTimes admins about? Message-ID: <75cb24520809261913j792e12e2i834142cd31976388@mail.gmail.com> Is there perhaps an about.com/nytimes.com admin around? I was wondering if they perhaps knew that their loadbalancer for www.nytimes.com is fairly broken wrt answering AAAA queries: (who's NS for nytimes.com) dig NS nytimes.com +short ns1t.nytimes.com. nydns2.about.com. nydns1.about.com. (who do they think is the NS for www.nytimes.com) dig www.nytimes.com @ns1t.nytimes.com. NS ;; QUESTION SECTION: ;www.nytimes.com. IN NS ;; AUTHORITY SECTION: www.nytimes.com. 60 IN NS nss1.sea1.nytimes.com. www.nytimes.com. 60 IN NS nss1.lga2.nytimes.com. (what is the AAAA for www.nytimes.com ?? ) dig www.nytimes.com @nss1.sea1.nytimes.com. AAAA ;www.nytimes.com. IN AAAA ;; AUTHORITY SECTION: . 3600000 IN NS k.root-servers.net. . 3600000 IN NS l.root-servers.net. . 3600000 IN NS m.root-servers.net. . 3600000 IN NS a.root-servers.net. . 3600000 IN NS b.root-servers.net. . 3600000 IN NS c.root-servers.net. . 3600000 IN NS d.root-servers.net. . 3600000 IN NS e.root-servers.net. . 3600000 IN NS f.root-servers.net. . 3600000 IN NS g.root-servers.net. . 3600000 IN NS h.root-servers.net. . 3600000 IN NS i.root-servers.net. . 3600000 IN NS j.root-servers.net. ;; ADDITIONAL SECTION: k.root-servers.net. 3600000 IN A 193.0.14.129 l.root-servers.net. 3600000 IN A 198.32.64.12 m.root-servers.net. 3600000 IN A 202.12.27.33 ;; Query time: 89 msec ;; SERVER: 170.149.172.35#53(170.149.172.35) wha??? Lucy, your loadbalancer is foobar'd In an effort to make v6 things work a tad better in this hostile world, could the NYTimes folks let us know what sort of LB that is? and why it wants to not be a good Intenet Citizen?? -Chris From morrowc.lists at gmail.com Fri Sep 26 22:07:18 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 26 Sep 2008 23:07:18 -0400 Subject: About.com/NYTimes admins about? In-Reply-To: <75cb24520809261913j792e12e2i834142cd31976388@mail.gmail.com> References: <75cb24520809261913j792e12e2i834142cd31976388@mail.gmail.com> Message-ID: <75cb24520809262007v7d7c45baw16f12b93e4182e02@mail.gmail.com> I hate to reply to myself, but... (and I'm sure this isn't the only other example) what the heck is ETrade's LB doing here? (who is NS for etrade.com) ;etrade.com. IN NS ;; ANSWER SECTION: etrade.com. 3212 IN NS dnsauth2.sys.gtei.net. etrade.com. 3212 IN NS dnsauth1.sys.gtei.net. etrade.com. 3212 IN NS ns1m7.etrade.com. etrade.com. 3212 IN NS ns2m7.etrade.com. etrade.com. 3212 IN NS auth40.ns.uu.net. etrade.com. 3212 IN NS ns1m4.etrade.com. etrade.com. 3212 IN NS ns2m3.etrade.com. (what's A for www.etrade.com @ns1m4.etrade.com) ;; QUESTION SECTION: ;www.etrade.com. IN A ;; AUTHORITY SECTION: www.etrade.com. 3600 IN NS gsched8.etrade.com. www.etrade.com. 3600 IN NS gsched4.etrade.com. www.etrade.com. 3600 IN NS gsched5.etrade.com. www.etrade.com. 3600 IN NS gsched7.etrade.com. sweet, now who is AAAA for www.etrade.com? ; <<>> DiG 9.4.0 <<>> AAAA @gsched5.etrade.com. www.etrade.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29630 ;; flags: qr aa rd; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; WARNING: Messages has 20 extra bytes at end ;; Query time: 28 msec ;; SERVER: 198.93.34.30#53(198.93.34.30) ;; WHEN: Sat Sep 27 02:42:27 2008 (or without recursion in the request: ; <<>> DiG 9.4.0 <<>> AAAA @gsched5.etrade.com. www.etrade.com +norecurse ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3362 ;; flags: qr aa; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: Messages has 20 extra bytes at end ;; Query time: 26 msec ;; SERVER: 198.93.34.30#53(198.93.34.30) ;; WHEN: Sat Sep 27 02:58:35 2008 ) what?? maybe the packet trace would help? Frame 1 (74 bytes on wire, 74 bytes captured) Arrival Time: Sep 27, 2008 03:02:52.198866000 [Time delta from previous captured frame: 0.000000000 seconds] [Time delta from previous displayed frame: 0.000000000 seconds] [Time since reference or first frame: 0.000000000 seconds] Frame Number: 1 Frame Length: 74 bytes Capture Length: 74 bytes [Frame is marked: False] [Protocols in frame: eth:ip:udp:dns] Ethernet II, Src: Intel_5c:b0:00 (00:0e:0c:5c:b0:00), Dst: Unispher_a0:3d:a5 (00:90:1a:a0:3d:a5) Destination: Unispher_a0:3d:a5 (00:90:1a:a0:3d:a5) Address: Unispher_a0:3d:a5 (00:90:1a:a0:3d:a5) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Source: Intel_5c:b0:00 (00:0e:0c:5c:b0:00) Address: Intel_5c:b0:00 (00:0e:0c:5c:b0:00) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol, Src: 1.1.1.1 (1.1.1.1), Dst: 198.93.34.30 (198.93.34.30) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 60 Identification: 0x0000 (0) Flags: 0x04 (Don't Fragment) 0... = Reserved bit: Not set .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11) Header checksum: 0x23c3 [correct] [Good: True] [Bad : False] Source: 1.1.1.1 (1.1.1.1) Destination: 198.93.34.30 (198.93.34.30) User Datagram Protocol, Src Port: 22479 (22479), Dst Port: domain (53) Source port: 22479 (22479) Destination port: domain (53) Length: 40 Checksum: 0x1728 [incorrect, should be 0x06ba (maybe caused by "UDP checksum offload"?)] [Good Checksum: False] [Bad Checksum: True] Domain Name System (query) Transaction ID: 0xfd35 Flags: 0x0000 (Standard query) 0... .... .... .... = Response: Message is a query .000 0... .... .... = Opcode: Standard query (0) .... ..0. .... .... = Truncated: Message is not truncated .... ...0 .... .... = Recursion desired: Don't do query recursively .... .... .0.. .... = Z: reserved (0) .... .... ...0 .... = Non-authenticated data OK: Non-authenticated data is unacceptable Questions: 1 Answer RRs: 0 Authority RRs: 0 Additional RRs: 0 Queries www.etrade.com: type AAAA, class IN Name: www.etrade.com Type: AAAA (IPv6 address) Class: IN (0x0001) Frame 2 (74 bytes on wire, 74 bytes captured) Arrival Time: Sep 27, 2008 03:02:52.226523000 [Time delta from previous captured frame: 0.027657000 seconds] [Time delta from previous displayed frame: 0.027657000 seconds] [Time since reference or first frame: 0.027657000 seconds] Frame Number: 2 Frame Length: 74 bytes Capture Length: 74 bytes [Frame is marked: False] [Protocols in frame: eth:ip:udp:dns] Ethernet II, Src: Unispher_a0:3d:a5 (00:90:1a:a0:3d:a5), Dst: Intel_5c:b0:00 (00:0e:0c:5c:b0:00) Destination: Intel_5c:b0:00 (00:0e:0c:5c:b0:00) Address: Intel_5c:b0:00 (00:0e:0c:5c:b0:00) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Source: Unispher_a0:3d:a5 (00:90:1a:a0:3d:a5) Address: Unispher_a0:3d:a5 (00:90:1a:a0:3d:a5) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol, Src: 198.93.34.30 (198.93.34.30), Dst:1.1.1.1 (1.1.1.1) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 60 Identification: 0x9fb6 (40886) Flags: 0x04 (Don't Fragment) 0... = Reserved bit: Not set .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 253 Protocol: UDP (0x11) Header checksum: 0xc70b [correct] [Good: True] [Bad : False] Source: 198.93.34.30 (198.93.34.30) Destination: 1.1.1.1 (1.1.1.1) User Datagram Protocol, Src Port: domain (53), Dst Port: 22479 (22479) Source port: domain (53) Destination port: 22479 (22479) Length: 40 Checksum: 0x82ba [correct] [Good Checksum: True] [Bad Checksum: False] Domain Name System (response) [Request In: 1] [Time: 0.027657000 seconds] Transaction ID: 0xfd35 Flags: 0x8400 (Standard query response, No error) 1... .... .... .... = Response: Message is a response .000 0... .... .... = Opcode: Standard query (0) .... .1.. .... .... = Authoritative: Server is an authority for domain .... ..0. .... .... = Truncated: Message is not truncated .... ...0 .... .... = Recursion desired: Don't do query recursively .... .... 0... .... = Recursion available: Server can't do recursive queries .... .... .0.. .... = Z: reserved (0) .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server .... .... .... 0000 = Reply code: No error (0) Questions: 0 Answer RRs: 0 Authority RRs: 0 Additional RRs: 0 2 packets captured It's interesting as an aside that the LB here pushes out a TTL255 packet... Maybe the ETrade folks are also listening and could comment public/private or just fix this? :) It'd be good to see what kind of LB this is, and what version of software it is running. -Chris On Fri, Sep 26, 2008 at 10:13 PM, Christopher Morrow wrote: > Is there perhaps an about.com/nytimes.com admin around? I was > wondering if they perhaps knew that their loadbalancer for > www.nytimes.com is fairly broken wrt answering AAAA queries: > > (who's NS for nytimes.com) > dig NS nytimes.com +short > ns1t.nytimes.com. > nydns2.about.com. > nydns1.about.com. > > (who do they think is the NS for www.nytimes.com) > dig www.nytimes.com @ns1t.nytimes.com. NS > ;; QUESTION SECTION: > ;www.nytimes.com. IN NS > > ;; AUTHORITY SECTION: > www.nytimes.com. 60 IN NS nss1.sea1.nytimes.com. > www.nytimes.com. 60 IN NS nss1.lga2.nytimes.com. > > (what is the AAAA for www.nytimes.com ?? ) > dig www.nytimes.com @nss1.sea1.nytimes.com. AAAA > ;www.nytimes.com. IN AAAA > > ;; AUTHORITY SECTION: > . 3600000 IN NS k.root-servers.net. > . 3600000 IN NS l.root-servers.net. > . 3600000 IN NS m.root-servers.net. > . 3600000 IN NS a.root-servers.net. > . 3600000 IN NS b.root-servers.net. > . 3600000 IN NS c.root-servers.net. > . 3600000 IN NS d.root-servers.net. > . 3600000 IN NS e.root-servers.net. > . 3600000 IN NS f.root-servers.net. > . 3600000 IN NS g.root-servers.net. > . 3600000 IN NS h.root-servers.net. > . 3600000 IN NS i.root-servers.net. > . 3600000 IN NS j.root-servers.net. > > ;; ADDITIONAL SECTION: > k.root-servers.net. 3600000 IN A 193.0.14.129 > l.root-servers.net. 3600000 IN A 198.32.64.12 > m.root-servers.net. 3600000 IN A 202.12.27.33 > > ;; Query time: 89 msec > ;; SERVER: 170.149.172.35#53(170.149.172.35) > > > wha??? Lucy, your loadbalancer is foobar'd > > In an effort to make v6 things work a tad better in this hostile > world, could the NYTimes folks let us know what sort of LB that is? > and why it wants to not be a good Intenet Citizen?? > > -Chris > From frnkblk at iname.com Sat Sep 27 00:24:48 2008 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 27 Sep 2008 00:24:48 -0500 Subject: high latency ds3 issue on unloaded line In-Reply-To: <50BC6D22-6B75-4F1A-8C39-356FFA8ABD7E@sopris.net> References: <48DD080B.1070402@tiedyenetworks.com> <53A6C7E936ED8544B1A2BC990D254F942EA6F76A2B@MEMEXG1.HOST.local> <50BC6D22-6B75-4F1A-8C39-356FFA8ABD7E@sopris.net> Message-ID: It would be quite the poorly implemented ATM-based transport system if DS-3's were over-provisioned. We're not talking about packet-based service, it should be transported as traditional SONET-mapped. Frank -----Original Message----- From: Ben Plimpton [mailto:bplimpton at sopris.net] Sent: Friday, September 26, 2008 2:35 PM To: mike Cc: nanog at nanog.org Subject: Re: high latency ds3 issue on unloaded line We've had a similar issue with a few of our Qwest DS3's. The solution has been 1 of the following.... 1) Qwest has over-provisioned the transit links on their atm network that the DS3 is riding and the during peak times of the day, the transit link becomes congested causing high latency not related to our traffic levels. So the congestion could be appearing beyond your local loop. 2) We also had an instance where qwest had an issue with the PVC on the atm switch that we connected into that was causing > 500ms of latency. Like you, we are in a small town served by older ATM switches, so you might just see if they can rebuild both sides to see if that clears it up. Sounds quacky, but after 12 hours of troubleshooting, that was the fix. Ben On Sep 26, 2008, at 12:59 PM, John Lee wrote: > Mike, > > Your latencies which suddenly appear for several hours and then go > away and do this on a regular basis sounds like a layer 2, facility > switching issue. As you indicated " the problem comes on during the > day and then lets up late in the evening" sounds like the under > lying facility is being switched back around the "long side" of the > SONET ring or other facility. Some carrier facilities are scheduled > for "one path or direction" say during the day that are supposed to > be for lower latency time periods for interactive work and then > switch for a lower cost, higher latency path in the evening when > computer to computer backups do not care. If you can plot the times > the issues start and end and that these occur daily during the week > and not on weekends etc that would be a strong indicator. > > John (ISDN) Lee > > ________________________________________ > From: mike [mike-nanog at tiedyenetworks.com] > Sent: Friday, September 26, 2008 12:04 PM > To: nanog at nanog.org > Subject: high latency ds3 issue on unloaded line > > Hello, > > I have a ds3 from qwest which has daily issues with insane > point-to-point latencies sometimes exceeding 1000ms for hours on end, > and which suddenly disappear, and does not appear to correspond with > actual measured link utilization (less than 20mbps most days). > > To make a long investigation short, the problem comes on during the > day and then lets up late in the evening. I have tested and examined > everything at the ip layer and no it's not high utilization, an ACL, > router cpu or bad hardware, no line errors or other issues visible > from > interface or controller stats. yes I have flushed all hardware, and I > have a 7204vxr/npe-400 with this single ds3. The only clue seems to be > millions of 'output drops' from qwest's side. And at night I can hit > popular ftp mirrors from a directly attached server and observe my > interface reporting about %100 utilization combined with my users and > customers, so yeah it really is a full line rate ds3. And historically > Mrtg always shows around 20mbps or less utilization and it's only > smokeping that goes off, usually in the afternoon when the point to > point latencies between my router and qwest start heading north, and > consistently at that. I also have another in house tool that takes 30 > second snapshots of my ds3 interface in order to catch short bursts > that > would be smoothed out with mrtg's 5 minute average, but during these > high latency times there aren't any spikes noted. And for added > confusion (or fun!), the latency can start at any utilization level - > I've observed it while we were pulling just 12mbps, and I have not had > it while we were doing 34mbps, only the time of day seems to be the > common factor. > > Qwest has not been able to identify the issue, only note that - > yeah, this really is happening when there is otherwise no real load on > the line - and I am certain we have done everything to rule out the ip > layer. They have put in a 'request' to move me to another router, > but I > am not hopeful of a resolution that way as the router we're > currently on > doesn't appear otherwise to have the problem with any other > subscriber. > > What I want to know, is it possible that the underlaying atm/sonet > that carries my ds3 from my facility is somehow oversubscribed or > misconfigured? We have an OC12 fiber entrance and this is the only > circuit provisioned on it, and in our small tiny town the only other > user on the ring with us is comcast (according to the att network > engineer who installed this). I don't know enough about atm/sonet to > imagine conditions that would cause the issues I am seeing here , but > every ip layer tool I have only ever tells me there isn't an ip issue > here. I can issue ping from my router directly to the attached qwest > router and get > 1000ms and then other times (out of the problem > window), I am getting 4ms. > > If anyone has laughs or beers to offer me, send 'em on cuz I could > use both right about now.... > > Mike- > From lear at cisco.com Sat Sep 27 00:36:02 2008 From: lear at cisco.com (Eliot Lear) Date: Sat, 27 Sep 2008 07:36:02 +0200 Subject: Estonian Cyber Security Strategy document -- now available online In-Reply-To: References: Message-ID: <48DDC642.4000701@cisco.com> On 9/26/08 4:08 PM, Gadi Evron wrote: > Hello. > > The Estonian cyber security strategy document is now available online. > I must say once again the concept of a national cyber security stance > is quite > interesting. But not new. It's something a number of governments have been advocating through the ITU-D, FIRST, the CoE Convention on Cybercrime, London Action Plan, etc. Good research has been done on this as well by institutions such as ETH. Eliot From riches at about.com Sat Sep 27 02:12:32 2008 From: riches at about.com (Robert Manning) Date: Sat, 27 Sep 2008 03:12:32 -0400 Subject: About.com/NYTimes admins about? In-Reply-To: <75cb24520809261913j792e12e2i834142cd31976388@mail.gmail.com> Message-ID: Hey Chris, I'll reply to you off list. Thanks for the heads up. -rjb On 9/26/08 10:13 PM, "Christopher Morrow" wrote: > Is there perhaps an about.com/nytimes.com admin around? I was > wondering if they perhaps knew that their loadbalancer for > www.nytimes.com is fairly broken wrt answering AAAA queries: > > (who's NS for nytimes.com) > dig NS nytimes.com +short > ns1t.nytimes.com. > nydns2.about.com. > nydns1.about.com. > > (who do they think is the NS for www.nytimes.com) > dig www.nytimes.com @ns1t.nytimes.com. NS > ;; QUESTION SECTION: > ;www.nytimes.com. IN NS > > ;; AUTHORITY SECTION: > www.nytimes.com. 60 IN NS nss1.sea1.nytimes.com. > www.nytimes.com. 60 IN NS nss1.lga2.nytimes.com. > > (what is the AAAA for www.nytimes.com ?? ) > dig www.nytimes.com @nss1.sea1.nytimes.com. AAAA > ;www.nytimes.com. IN AAAA > > ;; AUTHORITY SECTION: > . 3600000 IN NS k.root-servers.net. > . 3600000 IN NS l.root-servers.net. > . 3600000 IN NS m.root-servers.net. > . 3600000 IN NS a.root-servers.net. > . 3600000 IN NS b.root-servers.net. > . 3600000 IN NS c.root-servers.net. > . 3600000 IN NS d.root-servers.net. > . 3600000 IN NS e.root-servers.net. > . 3600000 IN NS f.root-servers.net. > . 3600000 IN NS g.root-servers.net. > . 3600000 IN NS h.root-servers.net. > . 3600000 IN NS i.root-servers.net. > . 3600000 IN NS j.root-servers.net. > > ;; ADDITIONAL SECTION: > k.root-servers.net. 3600000 IN A 193.0.14.129 > l.root-servers.net. 3600000 IN A 198.32.64.12 > m.root-servers.net. 3600000 IN A 202.12.27.33 > > ;; Query time: 89 msec > ;; SERVER: 170.149.172.35#53(170.149.172.35) > > > wha??? Lucy, your loadbalancer is foobar'd > > In an effort to make v6 things work a tad better in this hostile > world, could the NYTimes folks let us know what sort of LB that is? > and why it wants to not be a good Intenet Citizen?? > > -Chris > From fw at deneb.enyo.de Sat Sep 27 05:18:30 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 27 Sep 2008 12:18:30 +0200 Subject: About.com/NYTimes admins about? In-Reply-To: <75cb24520809261913j792e12e2i834142cd31976388@mail.gmail.com> (Christopher Morrow's message of "Fri, 26 Sep 2008 22:13:46 -0400") References: <75cb24520809261913j792e12e2i834142cd31976388@mail.gmail.com> Message-ID: <87bpy9x56x.fsf@mid.deneb.enyo.de> * Christopher Morrow: > wha??? Lucy, your loadbalancer is foobar'd To cope with this, a QNAME/QTYPE-specific lameness cache has been added to BIND (and probably other resolvers). So this is nothing new, unfortunately. From DaveHowe at gmx.co.uk Sat Sep 27 06:26:01 2008 From: DaveHowe at gmx.co.uk (Dave Howe) Date: Sat, 27 Sep 2008 12:26:01 +0100 Subject: breadcrumbs and collusion In-Reply-To: <48DCD977.2090807@cox.net> References: <48DCD977.2090807@cox.net> Message-ID: <48DE1849.10102@gmx.co.uk> Laurence F. Sheldon, Jr. wrote: > michael.dillon at bt.com wrote: >>> However, it makes little sense to close your gate to keep the stray >>> dogs out of your yard, if they can just come in via your neighbour's >>> gate and climb over the fences. >> >> It makes a lot of sense. Having closed your gate, and discovered >> a stray dog in your back yard, you can call the animal control >> people and they stand a good chance of catching that stray dog. > > > Like most NANAE ...eerrr...NANOG metaphors this one is broken. Well, the first draft had "junkies" rather than dogs, but I decided that would cause issues in itself. Cats might be a better analogy though, you can train a dog to know better.... > We are not talking about stray dogs, were are talking about bad behaviour. Indeed so. unlike a stray dog, one that gets into your yard doesn't just crap there, but all over the neighbourhood, leaving clear trails that lead back to you. > If I keep them from dealing that stuff in my parking lot I do several > things, in approximate priority order: > > My clean customers don't have to suffer any effects of the bad guys > being on my lot. surely, but they still get dog crap on their boots > The bad guys learn it is not a good place to try to deal. They don't care. as long as they can get into your community *somewhere* that is good enough, it doesn't matter to them where. > The Law knows one place they don't have to worry about. true, but the discussion wasn't regarding *not* keeping your yard clean, but was regarding warning your neighbours so *they* can keep their yard clean - and that there is a self-benefit (in that some of the dirt in your yard comes from any dogs allowed into theirs) that would make it reasonable to do so (and not unfair victimization of stray dogs) and any suggestion that the Law would trust, just because you booted out *one* set of dogs, that your yard would forever more remain clean, confuses me. Perhaps you could explain further? From tkapela at gmail.com Sat Sep 27 06:34:16 2008 From: tkapela at gmail.com (Anton Kapela) Date: Sat, 27 Sep 2008 06:34:16 -0500 Subject: high latency ds3 issue on unloaded line In-Reply-To: References: <48DD080B.1070402@tiedyenetworks.com> <53A6C7E936ED8544B1A2BC990D254F942EA6F76A2B@MEMEXG1.HOST.local> <50BC6D22-6B75-4F1A-8C39-356FFA8ABD7E@sopris.net> Message-ID: <2e9d8ae50809270434j324ba62br5daf93d9a0c46cb7@mail.gmail.com> Anyone considered this could simply be a case of a customer ds3 provisioned into a mpls ccc/l2ckt style upstream aggregate? Ie. Ppp/hdlc in mpls. It seems best to first contact Q and ask exactly how this thing is provisioned. -Tk On 9/27/08, Frank Bulk wrote: > It would be quite the poorly implemented ATM-based transport system if > DS-3's were over-provisioned. We're not talking about packet-based service, > it should be transported as traditional SONET-mapped. > > Frank > > -----Original Message----- > From: Ben Plimpton [mailto:bplimpton at sopris.net] > Sent: Friday, September 26, 2008 2:35 PM > To: mike > Cc: nanog at nanog.org > Subject: Re: high latency ds3 issue on unloaded line > > We've had a similar issue with a few of our Qwest DS3's. The solution > has been 1 of the following.... > > 1) Qwest has over-provisioned the transit links on their atm network > that the DS3 is riding and the during peak times of the day, the > transit link becomes congested causing high latency not related to our > traffic levels. So the congestion could be appearing beyond your > local loop. > > 2) We also had an instance where qwest had an issue with the PVC on > the atm switch that we connected into that was causing > 500ms of > latency. Like you, we are in a small town served by older ATM > switches, so you might just see if they can rebuild both sides to see > if that clears it up. Sounds quacky, but after 12 hours of > troubleshooting, that was the fix. > > Ben > > On Sep 26, 2008, at 12:59 PM, John Lee wrote: > >> Mike, >> >> Your latencies which suddenly appear for several hours and then go >> away and do this on a regular basis sounds like a layer 2, facility >> switching issue. As you indicated " the problem comes on during the >> day and then lets up late in the evening" sounds like the under >> lying facility is being switched back around the "long side" of the >> SONET ring or other facility. Some carrier facilities are scheduled >> for "one path or direction" say during the day that are supposed to >> be for lower latency time periods for interactive work and then >> switch for a lower cost, higher latency path in the evening when >> computer to computer backups do not care. If you can plot the times >> the issues start and end and that these occur daily during the week >> and not on weekends etc that would be a strong indicator. >> >> John (ISDN) Lee >> >> ________________________________________ >> From: mike [mike-nanog at tiedyenetworks.com] >> Sent: Friday, September 26, 2008 12:04 PM >> To: nanog at nanog.org >> Subject: high latency ds3 issue on unloaded line >> >> Hello, >> >> I have a ds3 from qwest which has daily issues with insane >> point-to-point latencies sometimes exceeding 1000ms for hours on end, >> and which suddenly disappear, and does not appear to correspond with >> actual measured link utilization (less than 20mbps most days). >> >> To make a long investigation short, the problem comes on during the >> day and then lets up late in the evening. I have tested and examined >> everything at the ip layer and no it's not high utilization, an ACL, >> router cpu or bad hardware, no line errors or other issues visible >> from >> interface or controller stats. yes I have flushed all hardware, and I >> have a 7204vxr/npe-400 with this single ds3. The only clue seems to be >> millions of 'output drops' from qwest's side. And at night I can hit >> popular ftp mirrors from a directly attached server and observe my >> interface reporting about %100 utilization combined with my users and >> customers, so yeah it really is a full line rate ds3. And historically >> Mrtg always shows around 20mbps or less utilization and it's only >> smokeping that goes off, usually in the afternoon when the point to >> point latencies between my router and qwest start heading north, and >> consistently at that. I also have another in house tool that takes 30 >> second snapshots of my ds3 interface in order to catch short bursts >> that >> would be smoothed out with mrtg's 5 minute average, but during these >> high latency times there aren't any spikes noted. And for added >> confusion (or fun!), the latency can start at any utilization level - >> I've observed it while we were pulling just 12mbps, and I have not had >> it while we were doing 34mbps, only the time of day seems to be the >> common factor. >> >> Qwest has not been able to identify the issue, only note that - >> yeah, this really is happening when there is otherwise no real load on >> the line - and I am certain we have done everything to rule out the ip >> layer. They have put in a 'request' to move me to another router, >> but I >> am not hopeful of a resolution that way as the router we're >> currently on >> doesn't appear otherwise to have the problem with any other >> subscriber. >> >> What I want to know, is it possible that the underlaying atm/sonet >> that carries my ds3 from my facility is somehow oversubscribed or >> misconfigured? We have an OC12 fiber entrance and this is the only >> circuit provisioned on it, and in our small tiny town the only other >> user on the ring with us is comcast (according to the att network >> engineer who installed this). I don't know enough about atm/sonet to >> imagine conditions that would cause the issues I am seeing here , but >> every ip layer tool I have only ever tells me there isn't an ip issue >> here. I can issue ping from my router directly to the attached qwest >> router and get > 1000ms and then other times (out of the problem >> window), I am getting 4ms. >> >> If anyone has laughs or beers to offer me, send 'em on cuz I could >> use both right about now.... >> >> Mike- >> > > > > > From hrlinneweh at sbcglobal.net Sat Sep 27 09:04:39 2008 From: hrlinneweh at sbcglobal.net (Henry Linneweh) Date: Sat, 27 Sep 2008 07:04:39 -0700 (PDT) Subject: rackmount managed PDUs Message-ID: <375958.97567.qm@web82907.mail.mud.yahoo.com> Here is my contribution to the PDU/UPS list, Eaton has long been in this business http://www.powerware.com/UPS/Products.asp#large -henry ----- Original Message ---- From: Paul Stewart To: Andrew D Kirch Cc: nanog at nanog.org Sent: Thursday, September 25, 2008 9:45:53 AM Subject: RE: rackmount managed PDUs We have a lot of APC managed power bars (zero U vertical, and 19" 1U rackmount) and they work great.? We SNMP manage them and access them via web - they just work, and work well for our needs.? Tripplite we've had issues with over time, especially their UPS units (SNMP sucks on them). Hope this helps a bit.. Take care, Paul -----Original Message----- From: Andrew D Kirch [mailto:trelane at trelane.net] Sent: Thursday, September 25, 2008 12:41 PM Cc: nanog at nanog.org Subject: Re: rackmount managed PDUs http://www.webpowerswitch.com/? I've used these quite a bit.? Depending on the model you can get per port or per zone power management, and it sends alerts if it's not in the state it's supposed to be, and some of them can auto kickover things like routers if they suddenly cant route (might be dangerous, I don't use this one except at the CPE) Andrew Justin M. Streiner wrote: > As much as I hate to tear people away from the Intercage/Atrivo > debacle and semi-tangential rants, I'll take one for the team and do > it :) > > I have an opportunity coming up to rebuild an existing machine room > space to an extent.? It's not a total gut-and-refit, but I'll at least > get to put in some new infrastructure.? That said, I'd be interested > in hearing about peoples' experiences with various rackmountable > managed PDUs. > > I have some Tripp Lite PDUMH30NETs that work well and are reasonably > priced, but they have a few quirks (no RS-232 console port, web > interface seems to be a little shaky with Firefox, etc) that would > become more annoying when scaled up to several rows of new rack > footprints.? I'm also open to using managed vertically mounted PDUs. > The plan is for each footprint to have "A" and B" feeds, so two > PDUMH30NETs would take up 4U per footprint, which is a bit much... > > I don't need to worry about distributing DC power - just AC. > > This site will be lights-out most of the time, so robust remote > management capabilities are a must. > > Any thoughts/insight are greatly appreciated. > > jms > ---------------------------------------------------------------------------- "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 morrowc.lists at gmail.com Sat Sep 27 10:33:47 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 27 Sep 2008 11:33:47 -0400 Subject: About.com/NYTimes admins about? In-Reply-To: References: <75cb24520809261913j792e12e2i834142cd31976388@mail.gmail.com> Message-ID: <75cb24520809270833p4b24013o9993a38406feb745@mail.gmail.com> On Sat, Sep 27, 2008 at 3:12 AM, Robert Manning wrote: > Hey Chris, I'll reply to you off list. > awesome, thanks! > Thanks for the heads up. > > -rjb > > > On 9/26/08 10:13 PM, "Christopher Morrow" wrote: > >> Is there perhaps an about.com/nytimes.com admin around? I was >> wondering if they perhaps knew that their loadbalancer for >> www.nytimes.com is fairly broken wrt answering AAAA queries: >> >> (who's NS for nytimes.com) >> dig NS nytimes.com +short >> ns1t.nytimes.com. >> nydns2.about.com. >> nydns1.about.com. >> >> (who do they think is the NS for www.nytimes.com) >> dig www.nytimes.com @ns1t.nytimes.com. NS >> ;; QUESTION SECTION: >> ;www.nytimes.com. IN NS >> >> ;; AUTHORITY SECTION: >> www.nytimes.com. 60 IN NS nss1.sea1.nytimes.com. >> www.nytimes.com. 60 IN NS nss1.lga2.nytimes.com. >> >> (what is the AAAA for www.nytimes.com ?? ) >> dig www.nytimes.com @nss1.sea1.nytimes.com. AAAA >> ;www.nytimes.com. IN AAAA >> >> ;; AUTHORITY SECTION: >> . 3600000 IN NS k.root-servers.net. >> . 3600000 IN NS l.root-servers.net. >> . 3600000 IN NS m.root-servers.net. >> . 3600000 IN NS a.root-servers.net. >> . 3600000 IN NS b.root-servers.net. >> . 3600000 IN NS c.root-servers.net. >> . 3600000 IN NS d.root-servers.net. >> . 3600000 IN NS e.root-servers.net. >> . 3600000 IN NS f.root-servers.net. >> . 3600000 IN NS g.root-servers.net. >> . 3600000 IN NS h.root-servers.net. >> . 3600000 IN NS i.root-servers.net. >> . 3600000 IN NS j.root-servers.net. >> >> ;; ADDITIONAL SECTION: >> k.root-servers.net. 3600000 IN A 193.0.14.129 >> l.root-servers.net. 3600000 IN A 198.32.64.12 >> m.root-servers.net. 3600000 IN A 202.12.27.33 >> >> ;; Query time: 89 msec >> ;; SERVER: 170.149.172.35#53(170.149.172.35) >> >> >> wha??? Lucy, your loadbalancer is foobar'd >> >> In an effort to make v6 things work a tad better in this hostile >> world, could the NYTimes folks let us know what sort of LB that is? >> and why it wants to not be a good Intenet Citizen?? >> >> -Chris >> > > > From ge at linuxbox.org Sat Sep 27 10:48:59 2008 From: ge at linuxbox.org (Gadi Evron) Date: Sat, 27 Sep 2008 10:48:59 -0500 (CDT) Subject: Estonian Cyber Security Strategy document -- now available online In-Reply-To: <48DDC642.4000701@cisco.com> References: <48DDC642.4000701@cisco.com> Message-ID: On Sat, 27 Sep 2008, Eliot Lear wrote: > On 9/26/08 4:08 PM, Gadi Evron wrote: >> Hello. >> >> The Estonian cyber security strategy document is now available online. >> I must say once again the concept of a national cyber security stance is >> quite >> interesting. > > But not new. It's something a number of governments have been advocating > through the ITU-D, FIRST, the CoE Convention on Cybercrime, London Action > Plan, etc. Good research has been done on this as well by institutions such > as ETH. And OECD. Gadi. > > Eliot > From frnkblk at iname.com Sat Sep 27 20:38:05 2008 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 27 Sep 2008 20:38:05 -0500 Subject: the Intercage mess In-Reply-To: <6cd462c00809241958w103ae971ya5038af0aa88975b@mail.gmail.com> References: <20080924133743.944847809@relayer.avian.org> <48DAF58B.8030507@gmail.com> <48DAF651.70608@psg.com> <6cd462c00809241928t3cfe214fn93ed7f38688112f7@mail.gmail.com> <1222311156.20200.1364.camel@petrie.sacredspiral.co.uk> <6cd462c00809241958w103ae971ya5038af0aa88975b@mail.gmail.com> Message-ID: I get the feeling, to a certain extent, that there is a certain kind of mob mentality such that since we *can* do it, and they are a little guy, that we should shut them down no matter what. So despite what seems their now honest attempts to clean up, some are bent on still shutting them down (to make an example out of them?). Not that it's not unreasonable 'punishment' for all years of abuse that was inflicted on Internet users, but if this is who "we" are, then I'm a little disappointed. Frank -----Original Message----- From: Paul Ferguson [mailto:fergdawgster at gmail.com] Sent: Wednesday, September 24, 2008 9:59 PM To: William Pitcock Cc: nanog at nanog.org Subject: Re: the Intercage mess -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Sep 24, 2008 at 7:52 PM, William Pitcock wrote: > On Wed, 2008-09-24 at 19:28 -0700, Paul Ferguson wrote: >> I think that _more_than_reasonable_ background research, historical >> record, etc. have met the qualifications of "civilized vernier". The >> outcry was, and is not, arbitrary. > > No, but forcing them offline now that they are taking a new approach to > handling abuse is ridiculous. > No -- I think that after 5 years of malicious activity, it was overdue. I'm sorry, but your efforts to get the last word here are in vain. Cheers, - - ferg p.s. And by the way, whether the badness has actually been purged from Atrivo/Intercage's IP address space remains to be seen -- previous similar claims have all been false. Time will tell -- may eyes are watching. -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI2v5Oq1pz9mNUZTMRAhaHAJ46OFbpGDap70pAEHlzLwOCiJpRhgCfRgM1 4Riwi5G0vWvtZZWyYt9mgKw= =4BP6 -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From hrlinneweh at sbcglobal.net Sat Sep 27 23:39:02 2008 From: hrlinneweh at sbcglobal.net (Henry Linneweh) Date: Sat, 27 Sep 2008 21:39:02 -0700 (PDT) Subject: Renesys Blog Article [Was: Re: the Intercage mess] Message-ID: <287210.40244.qm@web82902.mail.mud.yahoo.com> If a consensus can be reached here, we have seen a rise in this, that does raise concerns of a RIAA/MPAA type of mindset, which is detrimental ? vigilante Definition??vigi?lante (vij?? lan?t?, -l?n?-) noun 1. a member of a vigilance committee 2. any individual who acts outside of legal authority, often violently, to punish or avenge a crime, right a perceived wrong, etc. vigi?lan?tism (vij?? lan?tiz??m, -l?n?-; vij?? l?n tiz??m) noun the lawless, violent methods, spirit, etc. of vigilantes ? vigilantism Related Forms vig?i?lan??tist adjective ? vigilantism Usage Examples Noun used with modifier * 'Internet: But this has come under fire from many who see it as an example of 'Internet vigilantism ' that could destabilize Internet trading. Adjective modifier * self-appointed: We must, moreover, take action which is firm enough to pre-empt action by self-appointed vigilantes. ========================================================================= ----- Original Message ---- From: Gadi Evron To: Paul Ferguson Cc: nanog at nanog.org; nanog-post at rsuc.gweep.net Sent: Wednesday, September 24, 2008 6:02:21 PM Subject: Re: Renesys Blog Article [Was: Re: the Intercage mess] On Wed, 24 Sep 2008, Paul Ferguson wrote: > Just a side-note: Rensys has an interesting blog article up today on this > Atrivo/Intercage "mess": > > http://www.renesys.com/blog/2008/09/internet_vigilantism_1.shtml > > FYI, I have but one comment. There is a difference between Vigilantism as it is perceived today and Vigilantism as it is in the dictionary. It means neighborhood watch. When the Police is not around, that is something you need. "It's for the children". All in all, very nice blog post. While I feel I can not yet fully comment on the whole Atrivo / Intercage depeering movement, there is an underlying strategy to consider. I will comment at a later date. ? ? ? ? Gadi. From patrick at zill.net Sat Sep 27 23:55:49 2008 From: patrick at zill.net (Patrick Giagnocavo) Date: Sun, 28 Sep 2008 00:55:49 -0400 Subject: Renesys Blog Article [Was: Re: the Intercage mess] In-Reply-To: <287210.40244.qm@web82902.mail.mud.yahoo.com> References: <287210.40244.qm@web82902.mail.mud.yahoo.com> Message-ID: <48DF0E55.2050301@zill.net> Henry Linneweh wrote: > If a consensus can be reached here, we have seen a rise in this, that does raise concerns > of a RIAA/MPAA type of mindset, which is detrimental > > vigilante Definition vigi?lante (vij?? lan?t?, -l?n?-) It is not vigilantism, it is the common law, rooted in ancient English history, of the "shire reeve", who we now call the "sheriff". The original duty of the shire reeve, among other things, was that he was 1 man out of every 10 households, whose duty it was to check the locks and gates of each house and barn, before himself retiring for the night. Another name for the sheriff, is the "Conservator of the Peace", which is, that on behalf of the community, he ensures that there is peace. Each of the smaller networks connected to the larger Internet, has someone whose job it is to be sure that the "locks and gates" are shut. Telling everyone to be careful of the known thief and to take precautions against him, is not slander, libel, or vigilantism. Just common sense. --Patrick From trelane at trelane.net Sun Sep 28 02:10:10 2008 From: trelane at trelane.net (Andrew D Kirch) Date: Sun, 28 Sep 2008 03:10:10 -0400 Subject: Renesys Blog Article [Was: Re: the Intercage mess] In-Reply-To: <287210.40244.qm@web82902.mail.mud.yahoo.com> References: <287210.40244.qm@web82902.mail.mud.yahoo.com> Message-ID: <48DF2DD2.7090204@trelane.net> The price of freedom is eternal vigilance. Andrew Henry Linneweh wrote: > If a consensus can be reached here, we have seen a rise in this, that does raise concerns > of a RIAA/MPAA type of mindset, which is detrimental > > vigilante Definition vigi?lante (vij?? lan?t?, -l?n?-) > noun > 1. a member of a vigilance committee > 2. any individual who acts outside of legal authority, often violently, to punish or avenge a crime, right a perceived wrong, etc. > vigi?lan?tism (vij?? lan?tiz??m, -l?n?-; vij?? l?n tiz??m) > noun > the lawless, violent methods, spirit, etc. of vigilantes > > vigilantism Related Forms > vig?i?lan??tist adjective > > vigilantism Usage Examples > Noun used with modifier > * 'Internet: But this has come under fire from many who see it as an example of 'Internet vigilantism ' that could destabilize Internet trading. > Adjective modifier > * self-appointed: We must, moreover, take action which is firm enough to pre-empt action by self-appointed vigilantes. ========================================================================= > > > > ----- Original Message ---- > From: Gadi Evron > To: Paul Ferguson > Cc: nanog at nanog.org; nanog-post at rsuc.gweep.net > Sent: Wednesday, September 24, 2008 6:02:21 PM > Subject: Re: Renesys Blog Article [Was: Re: the Intercage mess] > > On Wed, 24 Sep 2008, Paul Ferguson wrote: > >> Just a side-note: Rensys has an interesting blog article up today on this >> Atrivo/Intercage "mess": >> >> http://www.renesys.com/blog/2008/09/internet_vigilantism_1.shtml >> >> FYI, >> > > I have but one comment. > > There is a difference between Vigilantism as it is perceived today and > Vigilantism as it is in the dictionary. It means > neighborhood watch. > > When the Police is not around, that is something you need. "It's for the > children". > > All in all, very nice blog post. While I feel I can not yet fully comment > on the whole Atrivo / Intercage depeering movement, there is an underlying > strategy to consider. I will comment at a later date. > > Gadi. > From ken.gilmour at gmail.com Sun Sep 28 11:44:30 2008 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Sun, 28 Sep 2008 10:44:30 -0600 Subject: Routing issue between ICE and Level3 Message-ID: <5b6f80200809280944l2c9c57d3gec79d0ded1d94350@mail.gmail.com> Good morning, Is there anyone on this list who works for ICE in Costa Rica? We are encountering some routing issues between you and Level 3 and Packet Exchange. Level3 ticket number is available on request. Please contact me off list. ?Hay alguien en esta lista, que trabaja para ICE en Costa Rica? Estamos tropezando con algunos problemas de enrutamiento entre usted y Level3 y Packet Exchange. Level3 n?mero de billete est? disponible a petici?n. Gracias! Thanks and regards, Ken From DaveHowe at gmx.co.uk Sun Sep 28 12:04:08 2008 From: DaveHowe at gmx.co.uk (Dave Howe) Date: Sun, 28 Sep 2008 18:04:08 +0100 Subject: breadcrumbs and collusion In-Reply-To: References: Message-ID: <48DFB908.50605@gmx.co.uk> michael.dillon at bt.com wrote: >> However, it makes little sense to close your gate to keep >> the stray dogs out of your yard, if they can just come in via >> your neighbour's gate and climb over the fences. > > It makes a lot of sense. Having closed your gate, and discovered > a stray dog in your back yard, you can call the animal control > people and they stand a good chance of catching that stray dog. sounds good. who do you propose would fit the "role" of dogcatcher in this case, and why haven't they caught the stray yet after 5 years? From dredd at megacity.org Sun Sep 28 15:27:43 2008 From: dredd at megacity.org (Derek J. Balling) Date: Sun, 28 Sep 2008 16:27:43 -0400 Subject: rackmount managed PDUs In-Reply-To: References: Message-ID: I've pretty much completely sworn off 0U/Vertical PDUs.[1] In my experience, unless you're able to have on-hand, prior to cutting checks, all of the following: sample cabinets, sample servers, sample PDUs, you will NOT end up with a combo that doesn't suck in some fashion. Whether it's PDUs that block access to rear rails (as APC's 0Us do, even in their own cabinets), or PDUs which have their supply cables come out of the PDU horizontally, blocking access to whole portions of the rear of the cabinet (as the HP 3-phase 208V60A PDUs do if used in anything other than the specially crafted HP cabinets). Never again. To be honest, we made the decision simply to dedicate 4U (and 2U of horizontal cable-management) to our cabinet PDUs, and it's a decision I don't regret. Cheers, D [1] http://blog.megacity.org/archives/2008/03/0u-pdus/ From rsk at gsp.org Sun Sep 28 16:15:02 2008 From: rsk at gsp.org (Rich Kulawiec) Date: Sun, 28 Sep 2008 17:15:02 -0400 Subject: Renesys Blog Article [Was: Re: the Intercage mess] In-Reply-To: <287210.40244.qm@web82902.mail.mud.yahoo.com> References: <287210.40244.qm@web82902.mail.mud.yahoo.com> Message-ID: <20080928211502.GA19871@gsp.org> I'll argue that the term "vigilante" doesn't belong in this conversation. (Apologies to those who have seen this reasoning elsewhere.) Nobody did anything *to* them, it's just that folks stopped doing things *for* them, as an act of self-defense after many years of non-stop, prolific abuse. ---Rsk From michael.dillon at bt.com Mon Sep 29 03:40:01 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 29 Sep 2008 09:40:01 +0100 Subject: Renesys Blog Article [Was: Re: the Intercage mess] In-Reply-To: <48DF0E55.2050301@zill.net> Message-ID: > It is not vigilantism, it is the common law, rooted in > ancient English history, of the "shire reeve", who we now > call the "sheriff". Reeve means "called", from the Germanic verb "rufen". In other words, this person is someone who is called to the duty by the shire. The point that has been raised about vigilantism is that the people taking action have not been appointed by the community and therefore are not answerable to the community, nor are there actions controllable in any way by the community. > The original duty of the shire reeve, among other things, was > that he was 1 man out of every 10 households, whose duty it > was to check the locks and gates of each house and barn, > before himself retiring for the night. In other words, this person checked the property of his peers. He was one of the community which selected him. > Each of the smaller networks connected to the larger > Internet, has someone whose job it is to be sure that the > "locks and gates" are shut. And those network security people generally don't hang out on NANOG. Instead they hang out in various security forums like MAAWG etc. --Michael Dillon From michael.dillon at bt.com Mon Sep 29 03:46:16 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 29 Sep 2008 09:46:16 +0100 Subject: breadcrumbs and collusion In-Reply-To: <48DFB908.50605@gmx.co.uk> Message-ID: > sounds good. who do you propose would fit the "role" of > dogcatcher in this case, and why haven't they caught the > stray yet after 5 years? The police fill the dogcatcher role here, and they have indeed caught and prosecuted the stray on the rare occasions when ISPs have contacted the police and provided clear evidence in a form that the police could use. There have also been cases where people have used other laws. For instance, if a spammer breaks a signed AUP and you disconnect him, then you can go to court and recover whatever penalties are in the contract. Of course if you are looking for a hero to catch the criminal mastermind behind all of the world's ills, in order to stop all crime once and for all, then you will be disappointed. --Michael Dillon From ww at styx.org Mon Sep 29 05:19:20 2008 From: ww at styx.org (William Waites) Date: Mon, 29 Sep 2008 12:19:20 +0200 Subject: [OT] Re: Sheriffs and Vigilantes In-Reply-To: References: Message-ID: <07F6675D-3811-44D2-92CC-E67AC62F5018@styx.org> Le 08-09-29 ? 10:40, a ?crit : >> It is not vigilantism, it is the common law, rooted in >> ancient English history, of the "shire reeve", who we now >> call the "sheriff". > > Reeve means "called", from the Germanic verb "rufen". > In other words, this person is someone who is called > to the duty by the shire. George Trevelyan's History of England gives the distinct impression that the sheriff was not quite so grass-roots an office as this thread might have one believe. The office was created at the instigation of the Norman monarchs so that they would have a parallel administrative structure from that of the feudal barons. This was to make it harder for the uppity barons to unseat the king as happened regularly in pre-Norman times. > In other words, this person checked the property of his > peers. He was one of the community which selected him. I wonder if the reeve (gerefa) was thought of as called by the community or by the king. Trevelyan and etymonline suggest the latter. Who, within the community, got to be sheriff was probably the community's choice. But once in office the sheriff was likely answerable to the king. In the absence of a monarch, is NANOG now trying to behave like the North American Regency Council? Hmmm... In Spain, a vigilante is a security guard, almost always unarmed, whose job it is to be vigilant and call the police if something bad happens and take temporary measures if possible in the meantime. That type of vigilante would seem to correspond quite closely with the job of the responsible network security/operations person. Cheers, -w -- William Waites VE2WSW http://www.irl.styx.org/ +49 30 8894 9942 CD70 0498 8AE4 36EA 1CD7 281C 427A 3F36 2130 E9F5 From aaron at wsc.ma.edu Mon Sep 29 09:33:37 2008 From: aaron at wsc.ma.edu (Childs, Aaron) Date: Mon, 29 Sep 2008 10:33:37 -0400 Subject: Live.com admin Message-ID: <3760B7E1B344364AA0384B231FE7BA6910A9CC30@ex-be1.ads.wsc.ma.edu> If there is an admin/postmaster for live.com on this list could you please contact me off-list? Thank you, Aaron ------------- Aaron Childs Assistant Director, Networking Westfield State College http://www.wsc.ma.edu/it/ "I would rather write 10,000 notes than one letter of the alphabet." -- Beethoven From mikebenden at gmail.com Mon Sep 29 10:10:48 2008 From: mikebenden at gmail.com (L. Gabriel Somlo) Date: Mon, 29 Sep 2008 11:10:48 -0400 Subject: Advice in dealing with BGP prefix hijacking Message-ID: <20080929151048.GA19783@hedwig.net.cmu.edu> Hi, I'm looking for advice on how to deal with a US ISP (names withheld to protect the guilty) which seems to repeatedly fat-finger our IP space into their BGP announcements, and then gives us the run-around when we call them on the phone, since we're not their clients... Happened twice already, took several hours to fix each time, and I'm looking for any ideas, opinions, and war stories that would help me figure out how to discourage them from repeating this type of thing in the future... Thaks much, Mike From warren at kumari.net Mon Sep 29 10:12:55 2008 From: warren at kumari.net (Warren Kumari) Date: Mon, 29 Sep 2008 11:12:55 -0400 Subject: NANOG 44 (Los Angeles): ISP Security BOF Message-ID: Hi all, NANOG 44 is fast approaching and once again we are looking for topics for the ISP Security BOF. If you have any security related topics that you would like to hear about, not hear about, or (best of all) speak about, please let me know as soon as possible... This is your chance to air your views --- slides are welcome but not required. Danny McPherson and I are going to be moderating this year... W From CHRISTINE.M.BERNS at sargentlundy.com Mon Sep 29 11:13:09 2008 From: CHRISTINE.M.BERNS at sargentlundy.com (CHRISTINE.M.BERNS at sargentlundy.com) Date: Mon, 29 Sep 2008 11:13:09 -0500 Subject: BGP for disaster recovery site Message-ID: We currently have a routable block (class B) of IP addresses. We are in the process of designing a disaster recovery site. Our main site is already dual homed to two different Internet service providers via BGP. A consultant told us that in order to allow us to test access to the DR site without affecting the production environment, we should get another block of addresses from ARIN and advertise those addresses out the DR site's Internet connection. Can we even expect to get another block from ARIN if we already have a class B, and could we not accomplish the same thing by advertising a subnet of our existing Class B at the DR site? I would actually prefer to advertise a subnet of our class B, but am wondering if there are any reasons why this is not a good idea. Also, I have seen reference to some Internet service providers possibly not accepting /24 BGP routes and either dropping them or aggregating them to a /21 or /20 or /19. Are there recommendations as to what is the longest prefix that we should advertise to guarantee that the prefix will be advertised throughout the Internet? Chris From streiner at cluebyfour.org Mon Sep 29 11:29:37 2008 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 29 Sep 2008 12:29:37 -0400 (EDT) Subject: BGP for disaster recovery site In-Reply-To: References: Message-ID: On Mon, 29 Sep 2008, CHRISTINE.M.BERNS at sargentlundy.com wrote: > We currently have a routable block (class B) of IP addresses. We are in > the process of designing a disaster recovery site. Our main site is > already dual homed to two different Internet service providers via BGP. A > consultant told us that in order to allow us to test access to the DR site > without affecting the production environment, we should get another block > of addresses from ARIN and advertise those addresses out the DR site's > Internet connection. Can we even expect to get another block from ARIN if > we already have a class B, and could we not accomplish the same thing by > advertising a subnet of our existing Class B at the DR site? I would > actually prefer to advertise a subnet of our class B, but am wondering if > there are any reasons why this is not a good idea. Also, I have seen > reference to some Internet service providers possibly not accepting /24 > BGP routes and either dropping them or aggregating them to a /21 or /20 > or /19. Are there recommendations as to what is the longest prefix > that we should advertise to guarantee that the prefix will be advertised > throughout the Internet? If you have a subnet or two within your /16 that you're not using at all today, you could use those to advertise from your DR site. If you're using all of your /16 today, then you could apply to ARIN for more space, but keep in mind that just because you have a /16 today doesn't mean that ARIN will automatically hand you another /16 because you're running a DR site. It is true that some providers might filter /24s out of 'legacy class B' space, however most providers I've seen are also loath to scribble on advertisements that they don't originate, i.e. aggregating smaller prefixes from your /16 back into that /16 if the origin AS isn't theirs. It might also be a good idea to register route-objects with one of the routing registries (RADB, ALTDB, ARIN, etc...) since some providers do build their routing policies based on information from those sources. There is no 100% guarantee of global reachability on any prefix you or anyone else advertises - just a reasonable expectation that things will work for the most part :) jms From fergdawgster at gmail.com Mon Sep 29 12:12:21 2008 From: fergdawgster at gmail.com (Paul Ferguson) Date: Mon, 29 Sep 2008 10:12:21 -0700 Subject: Renesys Blog Article [Was: Re: the Intercage mess] In-Reply-To: References: <48DF0E55.2050301@zill.net> Message-ID: <6cd462c00809291012m228aacd0nba3b633ae6ef5a8f@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Sep 29, 2008 at 1:40 AM, wrote: > > And those network security people generally don't hang out > on NANOG. Instead they hang out in various security forums > like MAAWG etc. > Not sure why you assume that -- I'm sure there are plenty of "security folks" on the NANOG list, who may also follow other more specific security forums. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFI4Qxtq1pz9mNUZTMRAudrAJ43+kzwmoWVPe/W2go8JVpsvZAoygCgh1Xu grjzedQ5qhk05525tJ+80+4= =U0aF -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/ From bpfankuch at cpgreeley.com Mon Sep 29 12:59:23 2008 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Mon, 29 Sep 2008 11:59:23 -0600 Subject: Go daddy mail services admin Message-ID: <01759D50DC387C45A018FE1817CE27D751CBA4C379@CPExchange1.cpgreeley.com> Could I get a godaddy mail admin to contact me off list? Ive been working with a client who has a hosted website and mail services and lost the ability to communicate with their SMTP server about 6 weeks ago. Been through about 4 hours on the phone with Godaddy Support and Comcast. Thanks Blake Pfankuch Connecting Point of Greeley Network Engineer 970-356-7224 [cid:image001.jpg at 01C9222A.D05DF880][cid:image002.gif at 01C9222A.D05DF880] -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 2526 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 1642 bytes Desc: image002.gif URL: From LarrySheldon at cox.net Mon Sep 29 13:20:37 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Mon, 29 Sep 2008 13:20:37 -0500 Subject: Go daddy mail services admin In-Reply-To: <01759D50DC387C45A018FE1817CE27D751CBA4C379@CPExchange1.cpgreeley.com> References: <01759D50DC387C45A018FE1817CE27D751CBA4C379@CPExchange1.cpgreeley.com> Message-ID: <48E11C75.3040602@cox.net> Blake Pfankuch wrote: > Could I get a godaddy mail admin to contact me off list? Ive been > working with a client who has a hosted website and mail services and > lost the ability to communicate with their SMTP server about 6 weeks > ago. Been through about 4 hours on the phone with Godaddy Support > and Comcast. Just out of curiosity--which port is your client using? From surfer at mauigateway.com Mon Sep 29 15:23:14 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 29 Sep 2008 13:23:14 -0700 Subject: Advice in dealing with BGP prefix hijacking Message-ID: <20080929132314.7903A2E3@resin18.mta.everyone.net> --- mikebenden at gmail.com wrote: From: "L. Gabriel Somlo" I'm looking for advice on how to deal with a US ISP (names withheld to protect the guilty) which seems to repeatedly fat-finger our IP space into their BGP announcements, and then gives us the run-around when we call them on the phone, since we're not their clients... ------------------------------------------ Talk to their upstream(s) and ask them to filter the ISP properly. Show the upstreams evidence of the ISPs wrongful announcements from router commands, bgplay or other tools. scott From surfer at mauigateway.com Mon Sep 29 15:49:22 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 29 Sep 2008 13:49:22 -0700 Subject: BGP for disaster recovery site Message-ID: <20080929134922.7903AAAD@resin18.mta.everyone.net> Inline... --- CHRISTINE.M.BERNS at sargentlundy.com wrote: We currently have a routable block (class B) of IP addresses. We are in the process of designing a disaster recovery site. Our main site is already dual homed to two different Internet service providers via BGP. ------------------------------------------------ First, unless the first two bits of the first octet are "10" it's not a "Class B". It's a /16, which is the same size as a "Class B" but the first two bits of the first octet are not necessarily "10". Are these two sites (main and DR) in the same ASN? ------------------------------------------------- A consultant told us that in order to allow us to test access to the DR site without affecting the production environment, we should get another block of addresses from ARIN and advertise those addresses out the DR site's Internet connection. Can we even expect to get another block from ARIN if we already have a class B... ------------------------------------------------- I would consider another consultant if you have not used 80% of your current allocation. ARIN will not allocate anymore space until you hit 80% utilization ------------------------------------------------- ...and could we not accomplish the same thing by advertising a subnet of our existing Class B at the DR site? I would actually prefer to advertise a subnet of our class B, but am wondering if there are any reasons why this is not a good idea. ------------------------------------------------- If the two sites are not in the same AS it's not a good idea unless you're experienced with such things. See past posts in the archives about the subject. ----------------------------------------------- Also, I have seen reference to some Internet service providers possibly not accepting /24 BGP routes and either dropping them or aggregating them to a /21 or /20 or /19. Are there recommendations as to what is the longest prefix that we should advertise to guarantee that the prefix will be advertised throughout the Internet? --------------------------------------------------- Nothing is ever guaranteed WRT routing certain prefix sizes on the internet, but you should have no problems with a /24. Any longer (a /25) and you will not have good connectivity on the internet. scott From mack at exchange.alphared.com Mon Sep 29 16:27:01 2008 From: mack at exchange.alphared.com (mack) Date: Mon, 29 Sep 2008 16:27:01 -0500 Subject: [nanog] Advice in dealing with BGP prefix hijacking In-Reply-To: References: Message-ID: <6F2FFD7C10F788479E354B84294036C459425B39@EXCH-MBX.exchange.alphared.local> First I would contact them, you have obviously done this and it didn't work since it happened again. Second I would contact their major transit providers, assuming they aren't a major transit provider themselves. If you share mutual transit providers then you will be most likely to get satisfactory results. If you aren't a customer of their transit provider then you may not get anywhere. Third you can contact ARIN to talk to the perpetrator and/or their transit providers. This is one of their primary functions. The final option is legal. IANAL (usual disclaimer) CMU probably has a legal department that may be able to request an injunction or file suit for damages. People tend to forget that when prefixes are hijacked there is legal recourse after the fact. Of course with the international nature of the internet legal recourse may be difficult or impossible. In this case with a US based ISP, the legal remedy might be feasible. This is long slow and doesn't help at all during an incident, but it will probably keep it from happening again. ISPs are businesses and when it hits the pocket book they pay attention. -- LR Mack McBride Network Administrator Alpha Red, Inc. > > Message: 2 > Date: Mon, 29 Sep 2008 11:10:48 -0400 > From: "L. Gabriel Somlo" > Subject: Advice in dealing with BGP prefix hijacking > To: nanog at nanog.org > Message-ID: <20080929151048.GA19783 at hedwig.net.cmu.edu> > Content-Type: text/plain; charset=us-ascii > > Hi, > > I'm looking for advice on how to deal with a US ISP (names withheld to > protect the guilty) which seems to repeatedly fat-finger our IP space > into their BGP announcements, and then gives us the run-around when we > call them on the phone, since we're not their clients... > > Happened twice already, took several hours to fix each time, and I'm > looking for any ideas, opinions, and war stories that would help me > figure out how to discourage them from repeating this type of thing > in the future... > > Thaks much, > > Mike > > From frnkblk at iname.com Mon Sep 29 22:07:04 2008 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 29 Sep 2008 22:07:04 -0500 Subject: Go daddy mail services admin In-Reply-To: <01759D50DC387C45A018FE1817CE27D751CBA4C379@CPExchange1.cpgreeley.com> References: <01759D50DC387C45A018FE1817CE27D751CBA4C379@CPExchange1.cpgreeley.com> Message-ID: This would be when a tcp traceroute would be very helpful in diagnosing the problem. Frank -----Original Message----- From: Blake Pfankuch [mailto:bpfankuch at cpgreeley.com] Sent: Monday, September 29, 2008 12:59 PM To: nanog at nanog.org Subject: Go daddy mail services admin Could I get a godaddy mail admin to contact me off list? Ive been working with a client who has a hosted website and mail services and lost the ability to communicate with their SMTP server about 6 weeks ago. Been through about 4 hours on the phone with Godaddy Support and Comcast. Thanks Blake Pfankuch Connecting Point of Greeley Network Engineer 970-356-7224 [cid:image001.jpg at 01C9222A.D05DF880][cid:image002.gif at 01C9222A.D05DF880] From bpfankuch at cpgreeley.com Tue Sep 30 08:21:52 2008 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Tue, 30 Sep 2008 07:21:52 -0600 Subject: Go daddy mail services admin In-Reply-To: References: <01759D50DC387C45A018FE1817CE27D751CBA4C379@CPExchange1.cpgreeley.com> Message-ID: <01759D50DC387C45A018FE1817CE27D751CBA4C477@CPExchange1.cpgreeley.com> Amazingly its not a route problem. Its actually confirmed an issue with the mail server. Hense me asking for a mail services admin. The issue is confirmed from 3 locations with 3 different ISP's and I do actually know whats going on. I can connect to the server, but it will not allow me to send messages, even when authenticated. Returns a 554. It has been doing this with legitimate mail. They do not have the ability to send outbound as they get a 554 from their home office. The secondary smtp server links me to spamhaus saying that it will not allow relay based on an existing PBL entry. The PBL entry is because it's a residential DHCP connection, and the PBL entry was put in place by the isp. Please see http://www.spamhaus.org/pbl/query/PBL191963 if you have questions. So. Again. Looking for a GoDaddy Mail services Admin. -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Monday, September 29, 2008 9:07 PM To: Blake Pfankuch; nanog at nanog.org Subject: RE: Go daddy mail services admin This would be when a tcp traceroute would be very helpful in diagnosing the problem. Frank -----Original Message----- From: Blake Pfankuch [mailto:bpfankuch at cpgreeley.com] Sent: Monday, September 29, 2008 12:59 PM To: nanog at nanog.org Subject: Go daddy mail services admin Could I get a godaddy mail admin to contact me off list? Ive been working with a client who has a hosted website and mail services and lost the ability to communicate with their SMTP server about 6 weeks ago. Been through about 4 hours on the phone with Godaddy Support and Comcast. Thanks Blake Pfankuch Connecting Point of Greeley Network Engineer 970-356-7224 [cid:image001.jpg at 01C9222A.D05DF880][cid:image002.gif at 01C9222A.D05DF880] From dale.turner at mountaincable.on.ca Tue Sep 30 09:51:32 2008 From: dale.turner at mountaincable.on.ca (Dale Turner) Date: Tue, 30 Sep 2008 10:51:32 -0400 Subject: Cisco interface - GB of transfer software Message-ID: <48E23CF4.9010709@mountaincable.on.ca> Good morning all, I hope my post isn't too off topic but I was wondering if anyone is using some open source or purchased software that would give me the monthly Data transfer from cisco switch ports so I can monitor/bill against some hosting customers. I know we can create our own but looking to see if there was something that anyone is using and recommends. Thank you very much Dale Turner From bpfankuch at cpgreeley.com Tue Sep 30 10:01:44 2008 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Tue, 30 Sep 2008 09:01:44 -0600 Subject: Cisco interface - GB of transfer software In-Reply-To: <48E23CF4.9010709@mountaincable.on.ca> References: <48E23CF4.9010709@mountaincable.on.ca> Message-ID: <01759D50DC387C45A018FE1817CE27D751CBA4C498@CPExchange1.cpgreeley.com> I would be interested in this as well. -----Original Message----- From: Dale Turner [mailto:dale.turner at mountaincable.on.ca] Sent: Tuesday, September 30, 2008 8:52 AM To: nanog at nanog.org Subject: Cisco interface - GB of transfer software Good morning all, I hope my post isn't too off topic but I was wondering if anyone is using some open source or purchased software that would give me the monthly Data transfer from cisco switch ports so I can monitor/bill against some hosting customers. I know we can create our own but looking to see if there was something that anyone is using and recommends. Thank you very much Dale Turner From charles at thewybles.com Tue Sep 30 10:08:47 2008 From: charles at thewybles.com (Charles Wyble) Date: Tue, 30 Sep 2008 08:08:47 -0700 Subject: Cisco interface - GB of transfer software In-Reply-To: <01759D50DC387C45A018FE1817CE27D751CBA4C498@CPExchange1.cpgreeley.com> References: <48E23CF4.9010709@mountaincable.on.ca> <01759D50DC387C45A018FE1817CE27D751CBA4C498@CPExchange1.cpgreeley.com> Message-ID: <48E240FF.1050903@thewybles.com> I like to use ntop (from ntop.org) for this, along with MRTG. Others prefer cacti. I found MRTG easier to setup. It comes down to personal preference. Blake Pfankuch wrote: > I would be interested in this as well. > > -----Original Message----- > From: Dale Turner [mailto:dale.turner at mountaincable.on.ca] > Sent: Tuesday, September 30, 2008 8:52 AM > To: nanog at nanog.org > Subject: Cisco interface - GB of transfer software > > Good morning all, > > I hope my post isn't too off topic but I was wondering if anyone is > using some open source or purchased software that would give me the > monthly Data transfer from cisco switch ports so I can monitor/bill > against some hosting customers. I know we can create our own but looking > to see if there was something that anyone is using and recommends. > > Thank you very much > > Dale Turner > > > > > -- Charles Wyble (818) 280 - 7059 http://charlesnw.blogspot.com CTO Known Element Enterprises / SoCal WiFI project From akennedy at cyberlinktech.com Tue Sep 30 10:21:16 2008 From: akennedy at cyberlinktech.com (Adam Kennedy) Date: Tue, 30 Sep 2008 11:21:16 -0400 Subject: rackmount managed PDUs In-Reply-To: References: Message-ID: <48E243EC.3060504@cyberlinktech.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have loved the Raritan 0U PDU's. Granted, we use APC Netshelter SX in our DC, but these work well with both APC PDU's and Raritan PX-PDU's. http://www.apc.com/resource/include/techspec_index.cfm?base_sku=AR7710 - -- Adam Kennedy Senior Network Administrator Cyberlink Technologies, Inc. Phone: 888-293-3693 Fax: 574-855-5761 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjiQ+sACgkQJXrxMJHscbJY+ACcC90F8iqMXkCYexoMdNGAcHV7 e+gAoNtOkJYwO8PF9FmXqdmK0E7OGkOe =dr98 -----END PGP SIGNATURE----- From dts at senie.com Tue Sep 30 10:39:11 2008 From: dts at senie.com (Daniel Senie) Date: Tue, 30 Sep 2008 11:39:11 -0400 Subject: Cisco interface - GB of transfer software In-Reply-To: <48E240FF.1050903@thewybles.com> References: <48E23CF4.9010709@mountaincable.on.ca> <01759D50DC387C45A018FE1817CE27D751CBA4C498@CPExchange1.cpgreeley.com> <48E240FF.1050903@thewybles.com> Message-ID: <200809301545.m8UFjSdF013942@parsley.amaranth.net> At 11:08 AM 9/30/2008, Charles Wyble wrote: >I like to use ntop (from ntop.org) for this, along with MRTG. Others >prefer cacti. I found MRTG easier to setup. It comes down to >personal preference. MRTG provides graphs of usage, but I'm not aware of it providing a monthly total usage (or 95% or other) in report form (though would be happy to learn otherwise). Does ntop provide a way to generate a monthly report? I believe the others posting are interested in this from a billing perspective. I share their interest. >Blake Pfankuch wrote: >>I would be interested in this as well. >> >>-----Original Message----- >>From: Dale Turner [mailto:dale.turner at mountaincable.on.ca] >>Sent: Tuesday, September 30, 2008 8:52 AM >>To: nanog at nanog.org >>Subject: Cisco interface - GB of transfer software >> >>Good morning all, >> >>I hope my post isn't too off topic but I was wondering if anyone is >>using some open source or purchased software that would give me the >>monthly Data transfer from cisco switch ports so I can monitor/bill >>against some hosting customers. I know we can create our own but looking >>to see if there was something that anyone is using and recommends. >> >>Thank you very much >> >>Dale Turner >> >> >> >> >> > > >-- >Charles Wyble (818) 280 - 7059 >http://charlesnw.blogspot.com >CTO Known Element Enterprises / SoCal WiFI project > From raymond at prolocation.net Tue Sep 30 10:52:07 2008 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Tue, 30 Sep 2008 17:52:07 +0200 (CEST) Subject: Cisco interface - GB of transfer software In-Reply-To: <200809301545.m8UFjSdF013942@parsley.amaranth.net> References: <48E23CF4.9010709@mountaincable.on.ca> <01759D50DC387C45A018FE1817CE27D751CBA4C498@CPExchange1.cpgreeley.com> <48E240FF.1050903@thewybles.com> <200809301545.m8UFjSdF013942@parsley.amaranth.net> Message-ID: Hi! >> I like to use ntop (from ntop.org) for this, along with MRTG. Others prefer >> cacti. I found MRTG easier to setup. It comes down to personal preference. > MRTG provides graphs of usage, but I'm not aware of it providing a monthly > total usage (or 95% or other) in report form (though would be happy to learn > otherwise). > > Does ntop provide a way to generate a monthly report? Check RTG. http://rtg.sourceforge.net/ Bye, Raymond. From jbates at brightok.net Tue Sep 30 10:58:27 2008 From: jbates at brightok.net (Jack Bates) Date: Tue, 30 Sep 2008 10:58:27 -0500 Subject: Cisco interface - GB of transfer software In-Reply-To: <200809301545.m8UFjSdF013942@parsley.amaranth.net> References: <48E23CF4.9010709@mountaincable.on.ca> <01759D50DC387C45A018FE1817CE27D751CBA4C498@CPExchange1.cpgreeley.com> <48E240FF.1050903@thewybles.com> <200809301545.m8UFjSdF013942@parsley.amaranth.net> Message-ID: <48E24CA3.8060500@brightok.net> Daniel Senie wrote: > MRTG provides graphs of usage, but I'm not aware of it providing a > monthly total usage (or 95% or other) in report form (though would be > happy to learn otherwise). > > Does ntop provide a way to generate a monthly report? > > I believe the others posting are interested in this from a billing > perspective. I share their interest. > Cacti and MRTG both have support for rrdtool backends. How the rrd is processed is up to you. A simple script to poll data and do some basic math and email the results, or generate a graph. Cacti has several plugins for sending reports. MRTG users tend to just script additionals. It's not as gui oriented as cacti, IMO. Each has pros and cons. If you have a sound internal php/mysql setup, cacti is a breeze and the plugin php scripts are cute for the non-techies. -Jack From frnkblk at iname.com Tue Sep 30 11:01:57 2008 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 30 Sep 2008 11:01:57 -0500 Subject: Go daddy mail services admin In-Reply-To: <01759D50DC387C45A018FE1817CE27D751CBA4C477@CPExchange1.cpgreeley.com> References: <01759D50DC387C45A018FE1817CE27D751CBA4C379@CPExchange1.cpgreeley.com> <01759D50DC387C45A018FE1817CE27D751CBA4C477@CPExchange1.cpgreeley.com> Message-ID: Blake: Sorry -- when you wrote "communicate" it wasn't clear if you had L3 connectivity to that server or not. All the best! Frank -----Original Message----- From: Blake Pfankuch [mailto:bpfankuch at cpgreeley.com] Sent: Tuesday, September 30, 2008 8:22 AM To: Frank Bulk; nanog at nanog.org Subject: RE: Go daddy mail services admin Amazingly its not a route problem. Its actually confirmed an issue with the mail server. Hense me asking for a mail services admin. The issue is confirmed from 3 locations with 3 different ISP's and I do actually know whats going on. I can connect to the server, but it will not allow me to send messages, even when authenticated. Returns a 554. It has been doing this with legitimate mail. They do not have the ability to send outbound as they get a 554 from their home office. The secondary smtp server links me to spamhaus saying that it will not allow relay based on an existing PBL entry. The PBL entry is because it's a residential DHCP connection, and the PBL entry was put in place by the isp. Please see http://www.spamhaus.org/pbl/query/PBL191963 if you have questions. So. Again. Looking for a GoDaddy Mail services Admin. -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Monday, September 29, 2008 9:07 PM To: Blake Pfankuch; nanog at nanog.org Subject: RE: Go daddy mail services admin This would be when a tcp traceroute would be very helpful in diagnosing the problem. Frank -----Original Message----- From: Blake Pfankuch [mailto:bpfankuch at cpgreeley.com] Sent: Monday, September 29, 2008 12:59 PM To: nanog at nanog.org Subject: Go daddy mail services admin Could I get a godaddy mail admin to contact me off list? Ive been working with a client who has a hosted website and mail services and lost the ability to communicate with their SMTP server about 6 weeks ago. Been through about 4 hours on the phone with Godaddy Support and Comcast. Thanks Blake Pfankuch Connecting Point of Greeley Network Engineer 970-356-7224 [cid:image001.jpg at 01C9222A.D05DF880][cid:image002.gif at 01C9222A.D05DF880] From bpfankuch at cpgreeley.com Tue Sep 30 11:03:22 2008 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Tue, 30 Sep 2008 10:03:22 -0600 Subject: Go daddy mail services admin In-Reply-To: References: <01759D50DC387C45A018FE1817CE27D751CBA4C379@CPExchange1.cpgreeley.com> <01759D50DC387C45A018FE1817CE27D751CBA4C477@CPExchange1.cpgreeley.com> Message-ID: <01759D50DC387C45A018FE1817CE27D751CBA4C4C8@CPExchange1.cpgreeley.com> Apologies about my response if it sounded a bit terse. I got about 30 private replies of "can you ping it? Can you telnet the smtp port?" -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Tuesday, September 30, 2008 10:02 AM To: Blake Pfankuch; nanog at nanog.org Subject: RE: Go daddy mail services admin Blake: Sorry -- when you wrote "communicate" it wasn't clear if you had L3 connectivity to that server or not. All the best! Frank -----Original Message----- From: Blake Pfankuch [mailto:bpfankuch at cpgreeley.com] Sent: Tuesday, September 30, 2008 8:22 AM To: Frank Bulk; nanog at nanog.org Subject: RE: Go daddy mail services admin Amazingly its not a route problem. Its actually confirmed an issue with the mail server. Hense me asking for a mail services admin. The issue is confirmed from 3 locations with 3 different ISP's and I do actually know whats going on. I can connect to the server, but it will not allow me to send messages, even when authenticated. Returns a 554. It has been doing this with legitimate mail. They do not have the ability to send outbound as they get a 554 from their home office. The secondary smtp server links me to spamhaus saying that it will not allow relay based on an existing PBL entry. The PBL entry is because it's a residential DHCP connection, and the PBL entry was put in place by the isp. Please see http://www.spamhaus.org/pbl/query/PBL191963 if you have questions. So. Again. Looking for a GoDaddy Mail services Admin. -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Monday, September 29, 2008 9:07 PM To: Blake Pfankuch; nanog at nanog.org Subject: RE: Go daddy mail services admin This would be when a tcp traceroute would be very helpful in diagnosing the problem. Frank -----Original Message----- From: Blake Pfankuch [mailto:bpfankuch at cpgreeley.com] Sent: Monday, September 29, 2008 12:59 PM To: nanog at nanog.org Subject: Go daddy mail services admin Could I get a godaddy mail admin to contact me off list? Ive been working with a client who has a hosted website and mail services and lost the ability to communicate with their SMTP server about 6 weeks ago. Been through about 4 hours on the phone with Godaddy Support and Comcast. Thanks Blake Pfankuch Connecting Point of Greeley Network Engineer 970-356-7224 [cid:image001.jpg at 01C9222A.D05DF880][cid:image002.gif at 01C9222A.D05DF880] From MBraun at firstam.com Tue Sep 30 11:18:38 2008 From: MBraun at firstam.com (Braun, Mike) Date: Tue, 30 Sep 2008 09:18:38 -0700 Subject: Cisco interface - GB of transfer software In-Reply-To: <48E24CA3.8060500@brightok.net> References: <48E23CF4.9010709@mountaincable.on.ca> <01759D50DC387C45A018FE1817CE27D751CBA4C498@CPExchange1.cpgreeley.com> <48E240FF.1050903@thewybles.com><200809301545.m8UFjSdF013942@parsley.amaranth.net> <48E24CA3.8060500@brightok.net> Message-ID: I have had good success with Netflow data to solve this, and if you don't mind spending a little money, Scrutinizer is a good tool to use. Mike -----Original Message----- From: Jack Bates [mailto:jbates at brightok.net] Sent: Tuesday, September 30, 2008 8:58 AM To: Daniel Senie Cc: nanog at nanog.org Subject: Re: Cisco interface - GB of transfer software Daniel Senie wrote: > MRTG provides graphs of usage, but I'm not aware of it providing a > monthly total usage (or 95% or other) in report form (though would be > happy to learn otherwise). > > Does ntop provide a way to generate a monthly report? > > I believe the others posting are interested in this from a billing > perspective. I share their interest. > Cacti and MRTG both have support for rrdtool backends. How the rrd is processed is up to you. A simple script to poll data and do some basic math and email the results, or generate a graph. Cacti has several plugins for sending reports. MRTG users tend to just script additionals. It's not as gui oriented as cacti, IMO. Each has pros and cons. If you have a sound internal php/mysql setup, cacti is a breeze and the plugin php scripts are cute for the non-techies. -Jack -- THIS E-MAIL MESSAGE AND ANY FILES TRANSMITTED HEREWITH, ARE INTENDED SOLELY FOR THE USE OF THE INDIVIDUAL(S) ADDRESSED AND MAY CONTAIN CONFIDENTIAL, PROPRIETARY OR PRIVILEGED INFORMATION. IF YOU ARE NOT THE ADDRESSEE INDICATED IN THIS MESSAGE (OR RESPONSIBLE FOR DELIVERY OF THIS MESSAGE TO SUCH PERSON) YOU MAY NOT REVIEW, USE, DISCLOSE OR DISTRIBUTE THIS MESSAGE OR ANY FILES TRANSMITTED HEREWITH. IF YOU RECEIVE THIS MESSAGE IN ERROR, PLEASE CONTACT THE SENDER BY REPLY E-MAIL AND DELETE THIS MESSAGE AND ALL COPIES OF IT FROM YOUR SYSTEM. From LarrySheldon at cox.net Tue Sep 30 11:19:18 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Tue, 30 Sep 2008 11:19:18 -0500 Subject: Go daddy mail services admin In-Reply-To: References: <01759D50DC387C45A018FE1817CE27D751CBA4C379@CPExchange1.cpgreeley.com> <01759D50DC387C45A018FE1817CE27D751CBA4C477@CPExchange1.cpgreeley.com> Message-ID: <48E25186.8010802@cox.net> Frank Bulk wrote: > Sorry -- when you wrote "communicate" it wasn't clear if you had L3 > connectivity to that server or not. Kinda sad, really. We used to teach people (even before Intartubes days) that "communication" or "connectivity" came in layers (I'm not sure we used that word, but we used the concept) and you needed to start at the bottom of the stack and figure out what worked so you could eliminate that from the trouble-shooting efforts. From shane at rulespace.com Tue Sep 30 11:31:11 2008 From: shane at rulespace.com (Shane Gibson) Date: Tue, 30 Sep 2008 09:31:11 -0700 Subject: Cisco interface - GB of transfer software In-Reply-To: <200809301545.m8UFjSdF013942@parsley.amaranth.net> References: <48E23CF4.9010709@mountaincable.on.ca> <01759D50DC387C45A018FE1817CE27D751CBA4C498@CPExchange1.cpgreeley.com> <48E240FF.1050903@thewybles.com> <200809301545.m8UFjSdF013942@parsley.amaranth.net> Message-ID: <48E2544F.8020708@rulespace.com> Dale Turner wrote: >>> I hope my post isn't too off topic but I was wondering if anyone is >>> using some open source or purchased software that would give me the >>> monthly Data transfer from cisco switch ports so I can monitor/bill >>> against some hosting customers. Dale, I use MRTG with the mrtg_totals.pl script. It does a pretty decent job: http://www.geocities.com/josef_wendel/mrtg_total.html If you're already running MRTG (or set it up), it's easy to add on to your environment. v/r Shane From randy at psg.com Tue Sep 30 11:45:19 2008 From: randy at psg.com (Randy Bush) Date: Tue, 30 Sep 2008 12:45:19 -0400 Subject: paix palo attitude Message-ID: <48E2579F.4020808@psg.com> we're looking at dropping 2/3 of a rack of routing research measurement kit into paix palo alto, and have some questions. considering the price of space and power, we want to kinda make sure we'll get the data we need. we are looking specifically for a large amount of bgp peering data, we hope that folk will give us bgp peering though we expect no in- or out-bound traffic. think analogously to route views, though the kit on our end will be grinding the beans much more finely, espressoBGP :). pnis are expensive. if we plug into the peering mesh, are any larger folk on it? if not, would we be better off at the linx, at de-cix, at amsix, in stockholm? private replies are probably better as this is not of general interest. thanks. randy From cmills at accessdc.com Tue Sep 30 11:59:08 2008 From: cmills at accessdc.com (Mills, Charles) Date: Tue, 30 Sep 2008 12:59:08 -0400 Subject: Cisco interface - GB of transfer software In-Reply-To: References: <48E23CF4.9010709@mountaincable.on.ca> <01759D50DC387C45A018FE1817CE27D751CBA4C498@CPExchange1.cpgreeley.com> <48E240FF.1050903@thewybles.com><200809301545.m8UFjSdF013942@parsley.amaranth.net><48E24CA3.8060500@brightok.net> Message-ID: <58E0B21FC367B24485855A1DBD96B0BB0DCA8A77@adc-prd-exch1.internal.accessdc.com> Same here. I bill my customers on 95% percentile. I use Advent's Manageengine Netflow Analyzer -----Original Message----- From: Braun, Mike [mailto:MBraun at firstam.com] Sent: Tuesday, September 30, 2008 12:19 PM To: Daniel Senie Cc: nanog at nanog.org Subject: RE: Cisco interface - GB of transfer software I have had good success with Netflow data to solve this, and if you don't mind spending a little money, Scrutinizer is a good tool to use. Mike -----Original Message----- From: Jack Bates [mailto:jbates at brightok.net] Sent: Tuesday, September 30, 2008 8:58 AM To: Daniel Senie Cc: nanog at nanog.org Subject: Re: Cisco interface - GB of transfer software Daniel Senie wrote: > MRTG provides graphs of usage, but I'm not aware of it providing a > monthly total usage (or 95% or other) in report form (though would be > happy to learn otherwise). > > Does ntop provide a way to generate a monthly report? > > I believe the others posting are interested in this from a billing > perspective. I share their interest. > Cacti and MRTG both have support for rrdtool backends. How the rrd is processed is up to you. A simple script to poll data and do some basic math and email the results, or generate a graph. Cacti has several plugins for sending reports. MRTG users tend to just script additionals. It's not as gui oriented as cacti, IMO. Each has pros and cons. If you have a sound internal php/mysql setup, cacti is a breeze and the plugin php scripts are cute for the non-techies. -Jack -- THIS E-MAIL MESSAGE AND ANY FILES TRANSMITTED HEREWITH, ARE INTENDED SOLELY FOR THE USE OF THE INDIVIDUAL(S) ADDRESSED AND MAY CONTAIN CONFIDENTIAL, PROPRIETARY OR PRIVILEGED INFORMATION. IF YOU ARE NOT THE ADDRESSEE INDICATED IN THIS MESSAGE (OR RESPONSIBLE FOR DELIVERY OF THIS MESSAGE TO SUCH PERSON) YOU MAY NOT REVIEW, USE, DISCLOSE OR DISTRIBUTE THIS MESSAGE OR ANY FILES TRANSMITTED HEREWITH. IF YOU RECEIVE THIS MESSAGE IN ERROR, PLEASE CONTACT THE SENDER BY REPLY E-MAIL AND DELETE THIS MESSAGE AND ALL COPIES OF IT FROM YOUR SYSTEM. This e-mail message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this e-mail message in error, please notify the sender immediately by telephone or e-mail and destroy the original message without making a copy. Thank you. Neither this information block, the typed name of the sender, nor anything else in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message. From paul at blacknight.com Tue Sep 30 15:42:20 2008 From: paul at blacknight.com (Paul Kelly :: Blacknight) Date: Tue, 30 Sep 2008 21:42:20 +0100 Subject: Cisco interface - GB of transfer software In-Reply-To: <48E23CF4.9010709@mountaincable.on.ca> References: <48E23CF4.9010709@mountaincable.on.ca> Message-ID: MRTG + GBGraph + 95th.pl allows for MB/GB/port/vlan and also 95th percentile on same. It doesn't take much to build a small report that picks up on the files left behind by 95th.pl and GBGraph. 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: Dale Turner [mailto:dale.turner at mountaincable.on.ca] > Sent: Tuesday, September 30, 2008 3:52 PM > To: nanog at nanog.org > Subject: Cisco interface - GB of transfer software > > Good morning all, > > I hope my post isn't too off topic but I was wondering if anyone is > using some open source or purchased software that would give me the > monthly Data transfer from cisco switch ports so I can monitor/bill > against some hosting customers. I know we can create our own > but looking > to see if there was something that anyone is using and recommends. > > Thank you very much > > Dale Turner > > > From cleary at nytimes.com Tue Sep 30 16:04:48 2008 From: cleary at nytimes.com (Brendan Cleary) Date: Tue, 30 Sep 2008 17:04:48 -0400 Subject: About.com/NYTimes admins about? In-Reply-To: <75cb24520809270833p4b24013o9993a38406feb745@mail.gmail.com> References: <75cb24520809261913j792e12e2i834142cd31976388@mail.gmail.com> <75cb24520809270833p4b24013o9993a38406feb745@mail.gmail.com> Message-ID: <48E29470.8060602@nytimes.com> I worked with Chris on this outside of the list. Replying here just to close the loop in case anyone else was interested. This situation is explained in this Case Study: http://support.citrix.com/article/CTX117947 The key sentence being: "In NetScaler software release 7.0, when the DNS server looks up AAAA records, the response was ?0? and errors ?0?. However, in NetScaler software release 8.0, with standard response ?0?, the NetScaler appliance sends the delegation records to root. " To summarize, if you don't have your NS records in place on the Netscalers, you will see a loop for AAAA queries (root>auth>netscaler>root....), eventually resulting in a SERVFAIL. Christopher Morrow wrote: > On Sat, Sep 27, 2008 at 3:12 AM, Robert Manning wrote: > >> Hey Chris, I'll reply to you off list. >> >> > > awesome, thanks! > > >> Thanks for the heads up. >> >> -rjb >> >> >> On 9/26/08 10:13 PM, "Christopher Morrow" wrote: >> >> >>> Is there perhaps an about.com/nytimes.com admin around? I was >>> wondering if they perhaps knew that their loadbalancer for >>> www.nytimes.com is fairly broken wrt answering AAAA queries: >>> >>> (who's NS for nytimes.com) >>> dig NS nytimes.com +short >>> ns1t.nytimes.com. >>> nydns2.about.com. >>> nydns1.about.com. >>> >>> (who do they think is the NS for www.nytimes.com) >>> dig www.nytimes.com @ns1t.nytimes.com. NS >>> ;; QUESTION SECTION: >>> ;www.nytimes.com. IN NS >>> >>> ;; AUTHORITY SECTION: >>> www.nytimes.com. 60 IN NS nss1.sea1.nytimes.com. >>> www.nytimes.com. 60 IN NS nss1.lga2.nytimes.com. >>> >>> (what is the AAAA for www.nytimes.com ?? ) >>> dig www.nytimes.com @nss1.sea1.nytimes.com. AAAA >>> ;www.nytimes.com. IN AAAA >>> >>> ;; AUTHORITY SECTION: >>> . 3600000 IN NS k.root-servers.net. >>> . 3600000 IN NS l.root-servers.net. >>> . 3600000 IN NS m.root-servers.net. >>> . 3600000 IN NS a.root-servers.net. >>> . 3600000 IN NS b.root-servers.net. >>> . 3600000 IN NS c.root-servers.net. >>> . 3600000 IN NS d.root-servers.net. >>> . 3600000 IN NS e.root-servers.net. >>> . 3600000 IN NS f.root-servers.net. >>> . 3600000 IN NS g.root-servers.net. >>> . 3600000 IN NS h.root-servers.net. >>> . 3600000 IN NS i.root-servers.net. >>> . 3600000 IN NS j.root-servers.net. >>> >>> ;; ADDITIONAL SECTION: >>> k.root-servers.net. 3600000 IN A 193.0.14.129 >>> l.root-servers.net. 3600000 IN A 198.32.64.12 >>> m.root-servers.net. 3600000 IN A 202.12.27.33 >>> >>> ;; Query time: 89 msec >>> ;; SERVER: 170.149.172.35#53(170.149.172.35) >>> >>> >>> wha??? Lucy, your loadbalancer is foobar'd >>> >>> In an effort to make v6 things work a tad better in this hostile >>> world, could the NYTimes folks let us know what sort of LB that is? >>> and why it wants to not be a good Intenet Citizen?? >>> >>> -Chris >>> >>> >> >> > > -- -Brendan Cleary Senior Network Engineer NYTIMES.COM 212.556.8041 From john at vanoppen.com Tue Sep 30 18:27:17 2008 From: john at vanoppen.com (John van Oppen) Date: Tue, 30 Sep 2008 16:27:17 -0700 Subject: Cisco interface - GB of transfer software References: <48E23CF4.9010709@mountaincable.on.ca> Message-ID: RTG is a great solution for 95th percentile if you are building your own system since it puts everything into an SQL database and comes with a nice php front end to start with. John van Oppen Spectrum Networks LLC 206.973.8302 (Direct) 206.973.8300 (main office) -----Original Message----- From: Paul Kelly :: Blacknight [mailto:paul at blacknight.com] Sent: Tuesday, September 30, 2008 1:42 PM To: 'dale.turner at mountaincable.on.ca'; 'nanog at nanog.org' Subject: RE: Cisco interface - GB of transfer software MRTG + GBGraph + 95th.pl allows for MB/GB/port/vlan and also 95th percentile on same. It doesn't take much to build a small report that picks up on the files left behind by 95th.pl and GBGraph. 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: Dale Turner [mailto:dale.turner at mountaincable.on.ca] > Sent: Tuesday, September 30, 2008 3:52 PM > To: nanog at nanog.org > Subject: Cisco interface - GB of transfer software > > Good morning all, > > I hope my post isn't too off topic but I was wondering if anyone is > using some open source or purchased software that would give me the > monthly Data transfer from cisco switch ports so I can monitor/bill > against some hosting customers. I know we can create our own > but looking > to see if there was something that anyone is using and recommends. > > Thank you very much > > Dale Turner > > > From dale.turner at mountaincable.on.ca Tue Sep 30 19:33:20 2008 From: dale.turner at mountaincable.on.ca (Dale Turner) Date: Tue, 30 Sep 2008 20:33:20 -0400 Subject: Cisco interface - GB of transfer software In-Reply-To: <48E23CF4.9010709@mountaincable.on.ca> References: <48E23CF4.9010709@mountaincable.on.ca> Message-ID: <48E2C550.8000800@mountaincable.on.ca> Thank you all for the recommendations. Cheers Dale Turner Dale Turner wrote: > Good morning all, > > I hope my post isn't too off topic but I was wondering if anyone is > using some open source or purchased software that would give me the > monthly Data transfer from cisco switch ports so I can monitor/bill > against some hosting customers. I know we can create our own but > looking to see if there was something that anyone is using and > recommends. > > Thank you very much > > Dale Turner > > > From ccaputo at alt.net Tue Sep 30 19:44:58 2008 From: ccaputo at alt.net (Chris Caputo) Date: Wed, 1 Oct 2008 00:44:58 +0000 (UTC) Subject: Exchange point tax-exempt status Message-ID: The Seattle IX (SIX) recently applied for and received an IRS tax-exemption due to its operation as a non-profit exchange point. In case there are any other non-profit exchange points that want to take this route, feel free to copy the relevant parts from our filing: http://www.seattleix.net/docs/20080703_IRS_Non_Profit_Filing.pdf Apparently the filing was sufficient, as there was no back and forth with the IRS. Three months passed and the IRS granted the exemption, per: http://www.seattleix.net/docs/20080911_IRS_501(c)(6)_Exemption_Letter.pdf Enjoy, Chris SIX Secretary/Treasurer From ernesto at cs.fiu.edu Tue Sep 30 23:41:12 2008 From: ernesto at cs.fiu.edu (Ernie Rubi) Date: Wed, 1 Oct 2008 00:41:12 -0400 Subject: 143.228.0.0/16 and house.gov Message-ID: Hi folks, just musing... From an ops perspective, wonder just how much traffic caused: "This morning, our engineers sounded the alarms ... and we have installed a digital version of a traffic cop. We enacted stopgaps that we planned for last night. We had hoped we didn't have to." --Jeff Ventura, communications director for the House's chief administrator. (from http://www.cnn.com/2008/POLITICS/09/30/congress.website/index.html) Don't .govs have enough b/w or at least ability to add b/w in order to satisfy their 'public outreach/information' role? (not a rhetorical question...hehe) It also seems to me that adding load balancing, firewall, throttling, etc methods for traffic shaping might actually make the problem worse by adding yet another layer(s) of hardware/software that may be prone to bottlenecking or overloading. whaddayathink? Ernie M. Rubi Network Engineer AMPATH/CIARA Florida International Univ, Miami From LarrySheldon at cox.net Tue Sep 30 23:45:30 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Tue, 30 Sep 2008 23:45:30 -0500 Subject: 143.228.0.0/16 and house.gov In-Reply-To: References: Message-ID: <48E3006A.4040102@cox.net> Ernie Rubi wrote: > whaddayathink? I think the house is run by the same folks that can't run a party-line vote. I'm surprised they have electric power. From sdhillon at decarta.com Tue Sep 30 23:51:26 2008 From: sdhillon at decarta.com (Sargun Dhillon) Date: Tue, 30 Sep 2008 21:51:26 -0700 Subject: 143.228.0.0/16 and house.gov References: Message-ID: <6C5C1804772DB944BA88A0DC48D338DA01518E84@dct-mail.sanjose.telcontar.com> I'm surprised it isn't outsourced to some managed (hosting) provider, or a CDN.. Like Akamai or LLNW. It would surely be far more efficient for their purposes. Also, if you've planned your network correctly QoS/Shaping will not negatively effect your network. You always engineer your outer edge to take a beating. Sargun Dhillon 925.202.9485 deCarta sdhillon at decarta.com www.decarta.com -----Original Message----- From: Ernie Rubi [mailto:ernesto at cs.fiu.edu] Sent: Tue 9/30/2008 21:41 To: nanog at nanog.org Subject: 143.228.0.0/16 and house.gov Hi folks, just musing... From an ops perspective, wonder just how much traffic caused: "This morning, our engineers sounded the alarms ... and we have installed a digital version of a traffic cop. We enacted stopgaps that we planned for last night. We had hoped we didn't have to." --Jeff Ventura, communications director for the House's chief administrator. (from http://www.cnn.com/2008/POLITICS/09/30/congress.website/index.html) Don't .govs have enough b/w or at least ability to add b/w in order to satisfy their 'public outreach/information' role? (not a rhetorical question...hehe) It also seems to me that adding load balancing, firewall, throttling, etc methods for traffic shaping might actually make the problem worse by adding yet another layer(s) of hardware/software that may be prone to bottlenecking or overloading. whaddayathink? Ernie M. Rubi Network Engineer AMPATH/CIARA Florida International Univ, Miami