- Test - lists.nanog.org

Seeking AIM/ICQ security contact
by Thomas Kernen 05 Jan '09

05 Jan '09

I'm looking for an AIM/ICQ security contact. If someone has any names I can direct my requests to please contact me unicast so we can keep the S/N as low as possible. Thanks Thomas

1 0

RE: Ethical DDoS drone network
by Ray Corbin 05 Jan '09

05 Jan '09

Until you get hit at 8GB/s and then don't have a nice 'off' button.. -r -----Original Message----- From: Michael Gazzerro [mailto:mike.gazzerro@nobistech.net] Sent: Monday, January 05, 2009 1:14 PM To: 'Jeffrey Lyon'; nanog(a)merit.edu Subject: RE: Ethical DDoS drone network You could just troll people on IRC until you get DDOS'd. All the fun, none of the work! -----Original Message----- From: Jeffrey Lyon [mailto:jeffrey.lyon@blacklotus.net] Sent: Monday, January 05, 2009 11:54 AM To: nanog(a)merit.edu Subject: Re: Ethical DDoS drone network FWIW, I'm primarily concerned about testing PPS loads and not brute force bandwidth. Best regards, Jeff On Mon, Jan 5, 2009 at 12:51 PM, Edward B. DREGER <eddy+public+spam(a)noc.everquick.net> wrote: > RD> Date: Mon, 5 Jan 2009 15:54:50 +0800 > RD> From: Roland Dobbins > > RD> AUPs are a big issue, here.. > > And AUPs [theoretically] set forth definitions. > > Of course, there exist colo providers with "unlimited 10 Gbps bandwidth" > whose AUPs read "do not use 'too much' bandwith or we will get angry", > thus introducing ambiguity regarding just _for what_ one is paying... > > Perhaps "abuse" is best _operationally_ defined as "something that > angers someone enough that it's at least sort of likely to cost you some > money -- and maybe even a lot"? > > Were the definition clear, I doubt there'd be such a long NANOG thread. > (Yes, I'm feeling optimistic today.) > > > 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(a)brics.com -*- jfconmaapaq(a)intc.net -*- sam(a)everquick.net > Sending mail to spambait addresses is a great way to get blocked. > Ditto for broken OOO autoresponders and foolish AV software backscatter. > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon(a)blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th at Booth #401.

2 2

Looking for verification that Google and Akamai have the geo-ip for 96.31.0.0/20 set correctly
by Frank Bulk - iName.com 05 Jan '09

05 Jan '09

We were assigned a new block from ARIN two weeks ago and are getting several reports from end users that the Spanish and German versions of Google's search page are coming up. IP2Location and Maxmind are mostly correct, but there appears to be no way for me to verify that Google and Akamai have 96.31.0.0/20 listed correctly. Perhaps someone can point me in the right direction so I can make an authoritative check. Thanks, Frank

7 8

108/8 and 184/8 allocated to ARIN
by Leo Vegoda 05 Jan '09

05 Jan '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, The IANA IPv4 registry has been updated to reflect the allocation of two /8 IPv4 blocks to ARIN in December 2008: 108/8 and 184/8. You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt Please update your filters as appropriate. Regards, Leo Vegoda Number Resources Manager, IANA -----BEGIN PGP SIGNATURE----- Version: 9.9.0.397 wj8DBQFJYcuzvBLymJnAzRwRAiHoAJ9ElxHBdXiQEYcWTE+QMKIA4+0rpwCgmbTy w5fYf3la3xtY5SjT5w+dS/w= =xUKB -----END PGP SIGNATURE-----

1 0

Re: Ethical DDoS drone network
by deleskie＠gmail.com 05 Jan '09

05 Jan '09

If the drones send a few packets a seconds even say 1000's of pkts per second its value is not likely to be very meaningful, atleast no more so then building an on net resourse. To be meaningful you'd want/need something that could simulate a DDoS. Maybe my assumptions are way off base. You'd also have the concern that if someone 'owned' you 'ethical' botnet being potentially responsible for any damage it caused. Maybe I'm just extra paranoid :) -jim ------Original Message------ From: Mark Foster To: deleskie(a)gmail.com Cc: Jeffrey Lyon Cc: nanog(a)merit.edu Subject: Re: Ethical DDoS drone network Sent: Jan 4, 2009 10:26 PM Refer earlier posts. End points ('drones') would have to be legitimate endpoints, not drones on random boxes. That eliminates legal liability client-side. If the traffic is non abusive then I don't see the risk for the network providers in the middle either. If it's clearly established that the source (drones), destination (target) are all 'opted in' and there's no 'collateral damage' (in bandwidth terms or otherwise, being the ways in which I see other parties potentially being impacted) I don't know that it's anywhere near as risky as you imply. You'd have to be careful not to trip IDS or similar for all the networks you transit, to avoid impacting on others in the event of some mis-fired responses... What would be an example legitimate security purpose, except to perhaps drill responses to illegitimate botnets? Mark. On Mon, 5 Jan 2009, deleskie(a)gmail.com wrote: > Super risky. This would be a 99% legal worry plus. Unless all the end points and networks they cross sign off on it the risk is beyond huge. > > -jim > ------Original Message------ > From: Jeffrey Lyon > Sender: > To: nanog(a)merit.edu > Subject: Ethical DDoS drone network > Sent: Jan 4, 2009 10:06 PM > > Say for instance one wanted to create an "ethical botnet," how would > this be done in a manner that is legal, non-abusive toward other > networks, and unquestionably used for legitimate internal security > purposes? How does your company approach this dilemma? > > Our company for instance has always relied on outside attacks to spot > check our security and i'm beginning to think there may be a more user > friendly alternative. > > Thoughts? > > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon(a)blacklotus.net | http://www.blacklotus.net > Black Lotus Communications of The IRC Company, Inc. > > Look for us at HostingCon 2009 in Washington, DC on August 10th - 12th > at Booth #401. > > > > Sent from my BlackBerry device on the Rogers Wireless Network Sent from my BlackBerry device on the Rogers Wireless Network

1 0

RE: Looking for verification that Google and Akamai have the geo-ip for 96.31.0.0/20 set correctly
by Skywing 05 Jan '09

05 Jan '09

Any "security" provided (I must assume that you speak of fraud prevention services) is the probablistic sort, of reducing, for example, aggregate (and not specific) losses. – S -----Original Message----- From: Greg Skinner <gds(a)gds.best.vwh.net> Sent: Sunday, January 04, 2009 15:52 To: Martin Hannigan <martin(a)theicelandguy.com> Cc: nanog(a)nanog.org <nanog(a)nanog.org> Subject: Re: Looking for verification that Google and Akamai have the geo-ip for 96.31.0.0/20 set correctly On Sat, Jan 03, 2009 at 01:31:28AM -0500, Martin Hannigan wrote: > Overall, geo location has turned out to be a somewhat valuable tool in terms > of language, fraud, and localization. I think that it's important to > continue to urge improvements in this technology, not divestment. I don't see how this technology can be improved past a certain point, because the criteria that are used to determine location are only coincidentally tied to location (they are the result of administrative policy and/or configuration). At best, they provide a false sense of "security". --gregbo

2 1

Sprint Leap Second
by Marshall Eubanks 05 Jan '09

05 Jan '09

Has anyone seen evidence that Sprint's cellular network has not adopted the leap second yet ? (I have reports, but cannot check myself.) Marshall

2 1

Gaza telecommunication systems offline
by Eric Brunner-Williams 04 Jan '09

04 Jan '09

This is sort of a rinse and repeat of the degradation of the Iraqi voice and data networks we annotated in March of 2003. The first is Ma'an (Turkish), the second is AP (American). Cell service is at the point of failure. Data is coming close to failure, and landline voice is problematic too. http://www.turkishweekly.net/news/62744/gaza-telecommunication-systems-offl… and http://www.google.com/hostednews/ukpress/article/ALeqM5iv4xv2KNWjkm8Ixw60eD… Eric

1 0

Re: Leap second tonight
by Peter Lothberg 04 Jan '09

04 Jan '09

bash-2.05b# date Thu Jan 1 00:59:58 CET 2009 bash-2.05b# date Thu Jan 1 00:59:59 CET 2009 bash-2.05b# date Thu Jan 1 00:59:60 CET 2009 bash-2.05b# date Thu Jan 1 01:00:00 CET 2009 bash-2.05b# date Thu Jan 1 01:00:01 CET 2009 bash-2.05b# -P

12 14

RE: Security team successfully cracks SSL using 200 PS3's and MD5 flaw.
by Skywing 04 Jan '09

04 Jan '09

That md5 has now been deprecated for awhile is certainly also true; and people should have definitely moved on by now. Then again, I just got yet another Debian DSA mail which has plaintext download links for new binaries. The integrity verification mechanism for said binaries is, you guessed it: PGP-signed md5sums. We still have a long way to go. :) – S -----Original Message----- From: Steven M. Bellovin <smb(a)cs.columbia.edu> Sent: Friday, January 02, 2009 15:07 To: Skywing <Skywing(a)valhallalegends.com> Cc: Deepak Jain <deepak(a)ai.net>; NANOG <nanog(a)nanog.org> Subject: Re: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. On Fri, 2 Jan 2009 16:51:53 -0600 Skywing <Skywing(a)valhallalegends.com> wrote: > Of course, md5 *used* to be good crypto. > See http://www.cs.columbia.edu/~smb/blog/2008-12/2008-12-30.html for the links, but MD5 has been suspect for a very long time. Dobbertin found problems with it in 1996. The need for caution with it was not just knowable but known, and stated publicly. I'm sure others did so as well; I can only easily quote my own works. From the second edition of my Firewalls book, in 2003: Additionally, \i{SHA} has replaced \i{MD5}, as the latter appears to be weaker than previously believed. and Hints of weakness have shown up in MD5 and RIPEMD-160; cautious people will eschew them, though none of the attacks are of use against either function when used with HMAC\@. As of this writing, the \i{NIST} algorithm appears to be the best choice. For many purposes, the newer versions of SHA are better; these have block sizes ranging from 256 to 512 bits. Even if that were not enough, Wang et al presented the actual collisions in 2004. There have been many updates and patches to more or less everything since then... Yes -- if you pick something that's very weak, you can get caught by surprise. But modern algorithms don't fall all at once. I should add, of course, that if you use bad algorithms or bad protocols, it doesn't matter where you store the public key. When I said that the update problem was easier, what I was saying is that you're not relying on outside parties for verification of identity, etc., it's all your own data. --Steve Bellovin, http://www.cs.columbia.edu/~smb

5 5