RE: Leap second tonight
A report from a DHCP/DNS appliance vendor here: Several customers have reported a complete lock-up of their Proteus system around the beginning of January 1st 2009. We believe that we have traced this to a problem in the underlying kernel and NTP and the handling of the date change associated with 2008 being a Leap Year and therefore having 366 days. Several conditions must be met to trigger this problem: 1. The Proteus was originally installed as v2.1.x or earlier. 2. NTP is enabled as a client with 2 or more external source servers defined. 3. There is a discrepancy in the times reported back by these other NTP servers. There is no correction available at this time, and the resolution is to power cycle the system, after which it will run fine. If you experienced a similar problem at the indicated time, please submit a trouble ticket so that we can confirm that this occurred on your system. I don't know what the underlying OS is. Frank -Original Message- From: Kevin Day [mailto:toa...@dragondata.com] Sent: Wednesday, December 31, 2008 4:42 PM To: NANOG list Subject: Leap second tonight Just a reminder that there's a leap second tonight. Last time I watched for what happened on 01/01/2006, there was a little bit of chaos: http://markmail.org/message/cpoj3jw5onzhhjkr?q=%22kevin+day%22+leap+second+r eminder+nanogpage=1refer=cnkxb3iv7sls5axu I've been told that some of the causes of these problems are fixed on any reasonably recent ntp distribution, but just in case, you might wanna keep an eye out if you're seeing any weirdness. The worst damage I'd heard from anyone after that event was their clock being significantly off for several hours. -- Kevin
Re: Leap second tonight
On Jan 5, 2009, at 11:30 AM, Adrian Chadd wrote: This begs the question - how the heck do timekeepers and politicians get away with last minute time changes? Surely there's -some- pushback from technology related interest groups to try and get more than four weeks warning? :) Having been involved in the leap second business, I can tell you that Daniel Gambis strictly follows the rules, which are Bulletin C is mailed every six months, either to announce a time step in UTC or to confirm that there will be no time step at the next possible date. If you want more lead time warning, pay attention to the LOD graph in http://hpiers.obspm.fr/eop-pc/ The long term LOD offset is about 1 msec now. That means that every day, Earth time and atomic time will drift off by 1 msec. Since there are 1000 msec in the second, and since the rule is that a leap second is chosen when the difference (UT1−UTC) approaches 0.9 seconds, projected out to the next period, and since the strong preference is to have leap seconds in January, you can generally figure out what will happen before Daniel announces it. For example, in one year the offset should be ~ 400 msec, so I will informally predict another leap second in January, 2011, not 2010. Keep watching that graph. Anyone who is dealing with Leap Second code should keep in mind that negative leap seconds (i.e., no second # 59, instead of an extra second called 60) are a distinct possibility. It all depends on the weather at the core mantle boundary - note that the LOD offset was almost 3 msec not too long ago. Regards Marshall Adrian On Mon, Jan 05, 2009, Frank Bulk wrote: A report from a DHCP/DNS appliance vendor here: Several customers have reported a complete lock-up of their Proteus system around the beginning of January 1st 2009. We believe that we have traced this to a problem in the underlying kernel and NTP and the handling of the date change associated with 2008 being a Leap Year and therefore having 366 days. Several conditions must be met to trigger this problem: 1. The Proteus was originally installed as v2.1.x or earlier. 2. NTP is enabled as a client with 2 or more external source servers defined. 3. There is a discrepancy in the times reported back by these other NTP servers. There is no correction available at this time, and the resolution is to power cycle the system, after which it will run fine. If you experienced a similar problem at the indicated time, please submit a trouble ticket so that we can confirm that this occurred on your system. I don't know what the underlying OS is. Frank -Original Message- From: Kevin Day [mailto:toa...@dragondata.com] Sent: Wednesday, December 31, 2008 4:42 PM To: NANOG list Subject: Leap second tonight Just a reminder that there's a leap second tonight. Last time I watched for what happened on 01/01/2006, there was a little bit of chaos: http://markmail.org/message/cpoj3jw5onzhhjkr?q=%22kevin+day%22+leap+second+r eminder+nanogpage=1refer=cnkxb3iv7sls5axu I've been told that some of the causes of these problems are fixed on any reasonably recent ntp distribution, but just in case, you might wanna keep an eye out if you're seeing any weirdness. The worst damage I'd heard from anyone after that event was their clock being significantly off for several hours. -- Kevin -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -
Re: Ethical DDoS drone network
On Mon, 05 Jan 2009 06:53:49 EST, Patrick W. Gilmore said: Knowing whether the systems - internal _and_ external - can handle a certain load (and figuring out why not, then fixing it) is vital to many people / companies / applications. Despite the rhetoric here, it is simply not possible to test that in a lab. And I guarantee if you do not test it, there _will_ be unexpected problems when Bad Stuff happens. Amen to that, brother. Trust me, you definitely want to do your load testing at a 2AM (or other usually dead time) of your own choosing, when you have the ability to pull the switch on the test almost instantly if it gets out of hand. The *last* think you want is to get a surprise slashdotting of your web servers while the police have your entire site under lockdown. Been there, done that, it's not fun. pgppPgLllT8di.pgp Description: PGP signature
Re: Ethical DDoS drone network
PWG Date: Mon, 5 Jan 2009 06:53:49 -0500 PWG From: Patrick W. Gilmore PWG But back to your original point, how can you tell it is shit data? AFAIK, RFC 3514 is the only standards document that has addressed this. I have yet to see it implemented. ;-) 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: dav...@brics.com -*- jfconmaa...@intc.net -*- s...@everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
108/8 and 184/8 allocated to ARIN
-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-
Re: Ethical DDoS drone network
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: dav...@brics.com -*- jfconmaa...@intc.net -*- s...@everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Leap second tonight
On 05/01/2009 6:01, Nick Hilliard n...@foobar.org wrote: [...] But seriously. Leap seconds occur every couple of years, either on July 30th and Dec 31. Sometimes both. And sometimes every consecutive year for a couple of years on the run. It's theoretically possible for leap seconds to be introduced at the end of March and September. It's never happened but it might, so I suppose software should allow for the possibility. Regards, Leo
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+s...@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: dav...@brics.com -*- jfconmaa...@intc.net -*- s...@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.l...@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.
RE: Ethical DDoS drone network
TAB Date: Mon, 5 Jan 2009 11:54:06 -0500 TAB From: BATTLES, TIMOTHY A (TIM), ATTLABS TAB assuming your somewhat scaled, I would think this could all be done TAB in the lab. And end up with a network that works in the lab. :-) - bw * delay - effects of flow caching, where applicable - jitter (esp. under load) - packet dups and loss (esp. under load) - packet reordering and assiciated side-effects - upstream/sidestream throughput (esp. under load) No, reality is far more complex. Some things do not lend themselves to _a priori_ models, nor even TFAR generalizations. 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: dav...@brics.com -*- jfconmaa...@intc.net -*- s...@everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Leap second tonight
Adrian Chadd wrote: This begs the question - how the heck do timekeepers and politicians get away with last minute time changes? Surely there's -some- pushback from technology related interest groups to try and get more than four weeks warning? :) Adrian The first notice I found was dated July 4th 2008 http://tycho.usno.navy.mil/bulletinc2008.html
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.l...@blacklotus.net] Sent: Monday, January 05, 2009 11:54 AM To: na...@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+s...@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: dav...@brics.com -*- jfconmaa...@intc.net -*- s...@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.l...@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.
Re: Ethical DDoS drone network
JL Date: Mon, 5 Jan 2009 12:54:24 -0500 JL From: Jeffrey Lyon JL FWIW, I'm primarily concerned about testing PPS loads and not brute JL force bandwidth. Which underscores my point: x bps with minimally-sized packets is even higher pps than x bps with normal-sized packets, for any non-minimal value of normal. Thus, the potential for breaking something that scales based on pps instead of bps _increases_ under such testing. I've not [yet] seen an AUP that reads customer shall maintain a minimum packet size of 400 bytes (combined IP header and payload) averaged over a moving one-hour window. ;-) 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: dav...@brics.com -*- jfconmaa...@intc.net -*- s...@everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
RE: Ethical DDoS drone network
Until you get hit at 8GB/s and then don't have a nice 'off' button.. -r -Original Message- From: Michael Gazzerro [mailto:mike.gazze...@nobistech.net] Sent: Monday, January 05, 2009 1:14 PM To: 'Jeffrey Lyon'; na...@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.l...@blacklotus.net] Sent: Monday, January 05, 2009 11:54 AM To: na...@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+s...@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: dav...@brics.com -*- jfconmaa...@intc.net -*- s...@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.l...@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.
Re: IPv6: IS-IS or OSPFv3
Thanks all for sharing information! regards Devang Patel On Mon, Jan 5, 2009 at 11:43 AM, Justin Shore jus...@justinshore.comwrote: Kevin Oberman wrote: I would hope you have a backbone well enough secured that you don't need to rely on this, but it does make me a bit more relaxed and makes me wish we were using ISIS for IPv4, as well. The time and disruption involved in converting is something that will keep us running OSPF for IPv4 for a long time, though. I remember the 'fun' of converting from IGRP to OSPF about 13 years ago and I'd prefer to retire before a repeat. I did the OSPF -- IS-IS migration some time back and here's some of the info I found at the time. http://www.nanog.org/meetings/nanog29/abstracts.php?pt=Njg2Jm5hbm9nMjk=nm=nanog29 Vijay did a nice presentation on AOL's migration to IS-IS. IIRC AOL migrated everything in 2 days. Day 1 was to migrate their test POP and hone their script. All remaining POPs were migrated on Day 2. I believe he said it went well. There have been several other documented migrations too: http://www.geant.net/upload/pdf/GEANT-OSPF-to-ISIS-Migration.pdf http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-eof-ospf.pdf I migrated my SP from a flat OSPF network (end to end area 0) to IS-IS. The OSPF setup was seriously screwed up. Someone got the bright idea to changes admin distances on some OSPF speakers, introduce a default in some places with static defaults in others, redistributing like it was going out of style, redisting a static for a large customer subnet on P2 instead of P1 which is what PE1 actually connected to (and not advertising the route from PE1 for some unknown reason), etc. The old setup was a nightmare. The IS-IS migration went fairly well after I got some major bugs worked out on our 7600s. I implemented IS-IS overtop of OSPF. Some OSPF speakers had admin distances of 80 and some were default. IS-IS slipped in over top with no problems. I raised IS-IS to 254 for the initial phase anyway just to be safe. Once I had IS-IS up I verified it learned all the expected routes via IS-IS. Then I lowered its admin distance back to the default and bumped OSPF up to 254. Shortly thereafter I nuked OSPF from each device. It was hitless. I never could get IS-IS to work with multiple areas. The 7600s made a smelly mess on the CO floor every time I tried. In the end I went with a L2-only IS-IS network. Still it works well for the most part. I've had about as much trouble with IS-IS as I have had with OSPF. Occasionally some random router will get a burr under it's saddle and jack up the MTU on the CLNS packets beyond the interface's max. The receiving router will drop the padded frame as too big. Fixing this can sometimes happen with a shut/no shut. Sometimes I can nuke the entire IS-IS config and re-add the config. Other times I simply have to reboot. This doesn't happen too often; it's usually several hours after I rock the IS-IS boat so to speak. Still, I wouldn't go back to OSPF for this SP. Justin
Re: Leap second tonight
On Tue, Jan 06, 2009 at 01:30:51AM +0900, Adrian Chadd wrote: This begs the question - how the heck do timekeepers and politicians get away with last minute time changes? Surely there's -some- pushback from technology related interest groups to try and get more than four weeks warning? :) Try six months. NTP itself sets the leap indicator by 28 days prior to the leap and clears it before the end of the following day, so in theory the appliance itself had at least 4 weeks notice and the rest of us had an additional five months. IERS announces a pending leap second six months in advance. The announcement for this one was dated July 4th. System vendors have only had 37 years since the first leap second to figure this out; please be patient. However, I can't excuse them for bugs surrounding the final day of a leap year. The Julian calendar is not exactly a new phenomenon. --msa
Re: Ethical DDoS drone network
Ray Corbin wrote: Until you get hit at 8GB/s and then don't have a nice 'off' button.. However, it would very accurately simulate a real-world attack where you don't get to have an off button. ~Seth
RE: Ethical DDoS drone network
But I don't think his boss would be too happy when their network is up and down for days because he irk'ed a scriptkiddie on irc just to test their limits :) -r -Original Message- From: Seth Mattinen [mailto:se...@rollernet.us] Sent: Monday, January 05, 2009 1:36 PM To: na...@merit.edu Subject: Re: Ethical DDoS drone network Ray Corbin wrote: Until you get hit at 8GB/s and then don't have a nice 'off' button.. However, it would very accurately simulate a real-world attack where you don't get to have an off button. ~Seth
RE: Leap second tonight
It's theoretically possible for leap seconds to be introduced at the end of March and September. As I recall, NTP supports leap seconds every month, for which there is a prediction that even this would be insufficient at some point in this millennium (depending, of course, on the actual rotation speed). There have been on again/off again talks to abolish the leap second for quite a number of years. Gary
Re: Leap second tonight
On Mon, Jan 05, 2009, Nick Hilliard wrote: Notice for the leap second was issued on July 4 2008. http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.36 Wow, how'd I miss that, I wonder? :) I'm just angry at the jack moves pulled by last minute timezone changes back in Australia, and the massively stupid repercussions seen throughout chunks of IT (incl. network auditing setups I had to poke at the time.) I'll add handling second == 60 to the list of things I should check for in my code. Thanks. :) Adrian
RE: Ethical DDoS drone network
There are some assumptions here. First are you considering volumetric DDOS attacks? Second, if you plan on harvesting wild bots and using them to serve your purpose then I don't see how this can be ethical unless they are just clients from your own network making it less distributed. You would then have to have this in your AUP allowing you to do this. Hmm, I really don't know what you would gain by this. Not knowing what your network looks like...but assuming your somewhat scaled, I would think this could all be done in the lab. -Original Message- From: Jeffrey Lyon [mailto:jeffrey.l...@blacklotus.net] Sent: Sunday, January 04, 2009 8:07 PM To: na...@merit.edu Subject: Ethical DDoS drone network 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.l...@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.
RE: Looking for verification that Google and Akamai have the geo-ip for 96.31.0.0/20 set correctly
Thanks for all those who responded on and off-list. Several persons confirmed for me using their Akamai account that the address space was correctly listed in Akamai's database, and between Google's quasi-generic online form (http://google.com/support/bin/request.py?contact_type=ip) and a Google employee, I think we'll get this straightened out. Frank -Original Message- From: Frank Bulk - iName.com [mailto:frnk...@iname.com] Sent: Friday, January 02, 2009 8:37 AM To: nanog@nanog.org Subject: Looking for verification that Google and Akamai have the geo-ip for 96.31.0.0/20 set correctly 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
Seeking AIM/ICQ security contact
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
Re: Ethical DDoS drone network
On Jan 5, 2009, at 3:39 AM, Gadi Evron wrote: On Sun, 4 Jan 2009, kris foster wrote: On Jan 4, 2009, at 11:11 PM, Gadi Evron wrote: On Mon, 5 Jan 2009, Patrick W. Gilmore wrote: On Jan 5, 2009, at 1:33 AM, Roland Dobbins wrote: On Jan 5, 2009, at 2:08 PM, Patrick W. Gilmore wrote: I can think of several instances where it _must_ be external. For instance, as I said before, knowing which intermediate networks are incapable of handling the additional load is useful information. But before any testing is done on production systems (during maintenance windows scheduled for this type of testing, naturally), it should all be done on airgapped labs, first, IMHO. Without arguing that point (and there are lots of scenarios where that is not at all necessary, IMHO), it does not change the fact that external testing can be extremely useful after air-gap testing. Fine test it by simulation on you or the transit end of the pipes. Do not transmit your test sh?t data across the `net. How do you propose a model is built for the simulation if you can't collect data from the real world? This is not sh?t data. Performance testing across networks is very real and happening now. The more knowledge I have of a path the better decisions I can make about that path. I am sorry for joking, I was sure we were talking about DDoS testing? I've been called by more one provider because I was DDoS'ing someone with traffic that someone requested. Strange how the word DDoS has morphed over time. But back to your original point, how can you tell it is shit data? DDoSes frequently use valid requests or even full connections. If I send my web server port 80 SYNs, why would you complain? Knowing whether the systems - internal _and_ external - can handle a certain load (and figuring out why not, then fixing it) is vital to many people / companies / applications. Despite the rhetoric here, it is simply not possible to test that in a lab. And I guarantee if you do not test it, there _will_ be unexpected problems when Bad Stuff happens. As mentioned before, Reality Land is not clean and structured. -- TTFN, patrick
Re: Ethical DDoS drone network
On Jan 5, 2009, at 2:54 AM, Roland Dobbins wrote: On Jan 5, 2009, at 3:04 PM, Patrick W. Gilmore wrote: I can think of several instances where it _must_ be external. For instance, as I said before, knowing which intermediate networks are incapable of handling the additional load is useful information. AUPs are a big issue, here.. No, they are not. AUPs do not stop me from sending traffic from my host to my host across links I am paying for. Without arguing that point (and there are lots of scenarios where that is not at all necessary, IMHO), it does not change the fact that external testing can be extremely useful after air-gap testing. Agree completely. You live in a very structured world. The idea is to instantiate structure in order to reduce the chaos. ; Most people live in reality-land where there are too many variables to control, and not only is it impossible guarantee that everything involved is strict to BCP, but the opposite is almost certainly true. Nothing's perfect, but one must do the basics before moving on to more advanced things. The low-hanging fruit, as it were (and of course, this is where scale becomes a major obstacle, in many cases; the fruit may be hanging low to the ground, but there can be a *lot* of it to pick). Perhaps we are miscommunicating. You seem to think I am saying people should test externally before they know whether their internal systems work. Of course that is a silly idea. That does not invalidate the need for external testing. Nor does it guarantee everything will be BCP compliant, especially since everything includes things outside your control. -- TTFN, patrick
RE: Ethical DDoS drone network
FWIW, I'm primarily concerned about testing PPS loads and not brute force bandwidth. Simple solution. Write some DDoS software that folks can install on their own machines. Make its so that the software is only triggered by commands from a device under the same administrative control, i.e. it uses a shared secret that is set up when folks install the software. So far there are two pieces of software, one pieces does the DDoSing, and the other piece controls it. You now need a third bit of software that sends DDoS requests to the controllers, and the controllers don't actually act upon such requests, but queue them until their administrators OK the DDoSing. Think of it a bit like a moderated mailing list. If you product that set of software, I'll bet that a lot of folks would be interested in working together to do DDoS stress testing of each others networks, at times of their own choosing. --Michael Dillon
Re: Leap second tonight
This begs the question - how the heck do timekeepers and politicians get away with last minute time changes? Surely there's -some- pushback from technology related interest groups to try and get more than four weeks warning? :) Adrian On Mon, Jan 05, 2009, Frank Bulk wrote: A report from a DHCP/DNS appliance vendor here: Several customers have reported a complete lock-up of their Proteus system around the beginning of January 1st 2009. We believe that we have traced this to a problem in the underlying kernel and NTP and the handling of the date change associated with 2008 being a Leap Year and therefore having 366 days. Several conditions must be met to trigger this problem: 1. The Proteus was originally installed as v2.1.x or earlier. 2. NTP is enabled as a client with 2 or more external source servers defined. 3. There is a discrepancy in the times reported back by these other NTP servers. There is no correction available at this time, and the resolution is to power cycle the system, after which it will run fine. If you experienced a similar problem at the indicated time, please submit a trouble ticket so that we can confirm that this occurred on your system. I don't know what the underlying OS is. Frank -Original Message- From: Kevin Day [mailto:toa...@dragondata.com] Sent: Wednesday, December 31, 2008 4:42 PM To: NANOG list Subject: Leap second tonight Just a reminder that there's a leap second tonight. Last time I watched for what happened on 01/01/2006, there was a little bit of chaos: http://markmail.org/message/cpoj3jw5onzhhjkr?q=%22kevin+day%22+leap+second+r eminder+nanogpage=1refer=cnkxb3iv7sls5axu I've been told that some of the causes of these problems are fixed on any reasonably recent ntp distribution, but just in case, you might wanna keep an eye out if you're seeing any weirdness. The worst damage I'd heard from anyone after that event was their clock being significantly off for several hours. -- Kevin -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -
Re: Leap second tonight
Adrian Chadd wrote: This begs the question - how the heck do timekeepers and politicians get away with last minute time changes? Surely there's -some- pushback from technology related interest groups to try and get more than four weeks warning? :) ? Notice for the leap second was issued on July 4 2008. http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.36 Nick
Re: Leap second tonight
Adrian Chadd wrote: Wow, how'd I miss that, I wonder? :) I would recommend lodging a complaint to the relevant authorities. That's sure to help. But seriously. Leap seconds occur every couple of years, either on July 30th and Dec 31. Sometimes both. And sometimes every consecutive year for a couple of years on the run. If your code insists on exactly 60 seconds in all minutes, or 86400 seconds in a hour, your code is wrong. You need to take this into account, because leap seconds are actually pretty common occurrences. I'm just angry at the jack moves pulled by last minute timezone changes back in Australia, and the massively stupid repercussions seen throughout chunks of IT (incl. network auditing setups I had to poke at the time.) I'll add handling second == 60 to the list of things I should check for in my code. Thanks. :) Yeah, last minute declarations are annoying. Like the british government's mad-cap idea to change VAT for the first time in donkey's years from 17.5% to 15% with 7 days warning. Now that's screwed up. Nick
Re: Security team successfully cracks SSL using 200 PS3's and MD5
On 2009-01-05, at 15:18, Jason Uhlenkott wrote: If we had DNSSEC, we could do away with SSL CAs entirely. The owner of each domain or host could publish a self-signed cert in a TXT RR, ... or even in a CERT RR, as I heard various clever people talking about in some virtual hallway the other day. http://www.isi.edu/in-notes/rfc2538.txt . and the DNS chain of trust would be the only form of validation needed. Joe
Re: Security team successfully cracks SSL using 200 PS3's and MD5
perhaps i am a bit slow. but could someone explain to me how trust in dns data transfers to trust in an http partner and other uses to which ssl is put? randy
Re: Security team successfully cracks SSL using 200 PS3's and MD5
On 2009-01-05, at 15:47, Randy Bush wrote: perhaps i am a bit slow. but could someone explain to me how trust in dns data transfers to trust in an http partner and other uses to which ssl is put? If I can get secure answers to www.bank.example IN CERT? and www.bank.example IN A? then perhaps when I connect to www.bank.example:443 I can decide to trust the certificate presented by the server based on the trust anchor I extracted from the DNS, rather than whatever trust anchors were bundled with my browser. That presumably would mean that the organisation responsible for bank.example could run their own CA and publish their own trust anchor, without having to buy that service from one of the traditional CA companies. No doubt there is more to it than that. I don't know anything much about X.509. Joe
Re: Security team successfully cracks SSL using 200 PS3's and MD5
On Fri, Jan 02, 2009 at 15:33:05 -0600, Joe Greco wrote: This would seem to point out some critical shortcomings in the current SSL system; these shortcomings are not necessarily technological, but rather social/psychological. We need the ability for Tom, Dick, or Harry to be able to crank out a SSL cert with a minimum of fuss or cost; having to learn the complexities of SSL is itself a fuss which has significantly and negatively impacted Internet security. Somehow, we managed to figure out how to do this with PGP and keysigning, but it all fell apart (I can hear the it doesn't scale already) with SSL. If we had DNSSEC, we could do away with SSL CAs entirely. The owner of each domain or host could publish a self-signed cert in a TXT RR, and the DNS chain of trust would be the only form of validation needed.
Re: Security team successfully cracks SSL using 200 PS3's and MD5
On 09.01.06 05:59, Joe Abley wrote: perhaps i am a bit slow. but could someone explain to me how trust in dns data transfers to trust in an http partner and other uses to which ssl is put? If I can get secure answers to www.bank.example IN CERT? and www.bank.example IN A? then perhaps when I connect to www.bank.example:443 I can decide to trust the certificate presented by the server based on the trust anchor I extracted from the DNS, rather than whatever trust anchors were bundled with my browser. That presumably would mean that the organisation responsible for bank.example could run their own CA and publish their own trust anchor, without having to buy that service from one of the traditional CA companies. No doubt there is more to it than that. I don't know anything much about X.509. x.509 is not the issue. it is your assumption that dns trust is formally transferrable to ssl/tls cert trust. to use your example, the contractor who serves dns for www.bank.example could insert a cert and then fake the web site having (a child of) that cert. whereas, if the site had its cert a descendant of the ca for all banks, this attack would fail. and i am not interested in quibbling about banks and who issues root cas. the point is that there are two different trust models here, and trust is not transitive. but then again, i have not even had coffee yet this morning. randy
RE: Ethical DDoS drone network
True, real world events differ, but so do denial of service attacks. Distribution in the network, PPS, BPS, Packet Type, Packet Size, etc.. Etc.. Etc.. So really I don't get the point either in staging a real life do it yourself test. So, you put pieces of your network in jeopardy night after night during maintenance windows to determine if what?? Your vulnerable to DDOS? We all know we are, it's just a question of what type and how much right? So we identify our choke points. We all know them. We look at the vendor data on how much PPS it can handle and quickly dismiss that. So what's the next step? Put the device that IS the choke point and pump it full of all different flavors until it fails. No harm no foul an now we have data regarding how much and what takes the device out. If the network is scaled, well we now know that we have x amount of devices that can fail if the DDOS goes X PPS with Y packet types. What I don't get is what you would be doing trying to accomplish this on a production network. Worse case is you break something. Best case is you don't. So if best case scenario is reach, what have you learned? Nothing! So what do you do next ramp it up? Seems silly. -Original Message- From: Edward B. DREGER [mailto:eddy+public+s...@noc.everquick.net] Sent: Monday, January 05, 2009 12:03 PM To: na...@merit.edu Subject: RE: Ethical DDoS drone network TAB Date: Mon, 5 Jan 2009 11:54:06 -0500 TAB From: BATTLES, TIMOTHY A (TIM), ATTLABS TAB assuming your somewhat scaled, I would think this could all be done TAB in the lab. And end up with a network that works in the lab. :-) - bw * delay - effects of flow caching, where applicable - jitter (esp. under load) - packet dups and loss (esp. under load) - packet reordering and assiciated side-effects - upstream/sidestream throughput (esp. under load) No, reality is far more complex. Some things do not lend themselves to _a priori_ models, nor even TFAR generalizations. 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: dav...@brics.com -*- jfconmaa...@intc.net -*- s...@everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Leap second tonight
I've gleened from this thread that: * everyone uses UTC, or should, because UTC is a uniform time scale, except for those leap seconds * UTC is sourced from the frequence of a radio emission from cesium atoms which are extremely constant * UTC can get out of whack with the rotation of the earth around the sun, because our rotation is not uniform, but is calculated rather than measured (well, sort of) * UTC is TAI plus leap seconds. In 1972, when leap seconds were first introduced, UTC was TAI - 10 seconds. UTC is now TAI - 34 seconds. TAI ticks exactly as fast as UTC, ignoring leap second adjustments. * UTC is slower than UT1 by about 1ms per day. * On 12/31/2008 UTC was (-) 591.8ms behind UT1. On 1/1/2008 UTC was 407.1ms ahead of UT1. * Leap seconds are applied to UTC every few years to remain in line with UT1, the time based on the rotation of the earth around the sun. * GMT is used to imply UT1, but sometimes UTC, but really GMT is just massively confusing and you shouldn't use it, either in conversation or in your servers/routers, because nobody is really sure without reading a lot of documentation what GMT means for each manufacturer/OS/software. * When writing code regarding dates and times, know that any year may have 366 days, and any minute may have 61 seconds. * When in doubt, Dr. Daniel Gambis is always right. Beckman On Mon, 5 Jan 2009, Marshall Eubanks wrote: Having been involved in the leap second business, I can tell you that Daniel Gambis strictly follows the rules, which are Bulletin C is mailed every six months, either to announce a time step in UTC or to confirm that there will be no time step at the next possible date. --- Peter Beckman Internet Guy beck...@angryox.com http://www.angryox.com/ ---
Re: Security team successfully cracks SSL using 200 PS3's and MD5
On Tue, 06 Jan 2009 06:09:34 +0900, Randy Bush said: to use your example, the contractor who serves dns for www.bank.example could insert a cert and then fake the web site having (a child of) that cert. whereas, if the site had its cert a descendant of the ca for all banks, this attack would fail. All you've done *there* is transfer the trust from the contractor to the company that's the ca for the bank. Yes, the ca-for-banks.com has a vested interest in making sure none of its employees go rogue and do something naughty - but so does the DNS contractor. One could equally well argue that if a site was using the DNS for certs would be immune to an attack on a CA. pgpOUfrEeXfx2.pgp Description: PGP signature
Re: Security team successfully cracks SSL using 200 PS3's and MD5
On 09.01.06 05:59, Joe Abley wrote: perhaps i am a bit slow. but could someone explain to me how trust in dns data transfers to trust in an http partner and other uses to which ssl is put? If I can get secure answers to www.bank.example IN CERT? and www.bank.example IN A? then perhaps when I connect to www.bank.example:443 I can decide to trust the certificate presented by the server based on the trust anchor I extracted from the DNS, rather than whatever trust anchors were bundled with my browser. That presumably would mean that the organisation responsible for bank.example could run their own CA and publish their own trust anchor, without having to buy that service from one of the traditional CA companies. No doubt there is more to it than that. I don't know anything much about X.509. x.509 is not the issue. it is your assumption that dns trust is formally transferrable to ssl/tls cert trust. to use your example, the contractor who serves dns for www.bank.example could insert a cert and then fake the web site having (a child of) that cert. whereas, if the site had its cert a descendant of the ca for all banks, this attack would fail. and i am not interested in quibbling about banks and who issues root cas. the point is that there are two different trust models here, and trust is not transitive. Sure it is. At least, sometimes it is. One of the problems I mentioned previously was that there's such an amount of fuss involved in obtaining SSL certs for relatively-low-value uses, and the end result is that many sites self-sign or simply don't bother. In the case where I've hosted a box with $BigHosterInc, and they've got DNS control of my zones, and they've got hands on the physical box(es), it becomes difficult to determine just how to prevent a bad actor at $BigHosterInc from do malicious things. On the flip side, there is very clearly value in differentiating between a certificate that merely guarantees that the communications between the server and your client is secure and not only that, but we certify that you are talking to a FooBank-owned web server. Trust is all relative. I might trust you, Randy Bush, in some particular way. But if a group of gunmen storm your home and force you to reveal some bit of confidential data I've given to you, is my trust misplaced, or is it simply that there are necessarily some limits and risks in sharing with you that confidential data? What is the difference if the information is something that gets someone killed, vs information that merely results in my company's business plans being known to a competitor? With that in mind, there could certainly be great uses for delegating some forms of trust through the DNS chain. Not all, though, not all. Banks are a good example of the circumstance where you'd want separation. but then again, i have not even had coffee yet this morning. Then have some coffee. ;-) ... 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.
Re: Security team successfully cracks SSL using 200 PS3's and MD5
Randy Bush wrote: perhaps i am a bit slow. but could someone explain to me how trust in dns data transfers to trust in an http partner and other uses to which ssl is put? randy It wouldn't, which is why the original suggestion is a bad idea. They're different issues (finding the actual address of the server you want to talk to vs. authenticating that the server is the server you want to talk to), and the trust doesn't transfer for multiple reasons. Mostly it isn't a good idea because there's a big too many eggs in one basket problem here... compromise of the DNS root keys not only would cause address lookups to be as insecure as they are now (which still works much of the time for many people), but inserting fake self-signed certs becomes trivial. This is nearly as bad as the argument I've seen that if we had DNSSEC we wouldn't even need SSL's authentication, because you'd be sure you were talking to the right server (never mind that there's demonstrated examples of just how easy it is to reroute someone else's packets from far away). Of course we could secure the entire routing system as well... Matthew Kaufman
Re: Leap second tonight
On 1/5/2009 at 1:19 PM, Peter Beckman beck...@angryox.com wrote: I've gleened from this thread that: * everyone uses UTC, or should, because UTC is a uniform time scale, except for those leap seconds Local time is totally appropriate in some circumstances, but it is pretty much always defined as just an offset to UTC. UT1 is important when you are doing astronomical observations or depend on such things. * UTC is sourced from the frequence of a radio emission from cesium atoms which are extremely constant There is nothing too special about cesium. It's properties and the properties of the particular transition are convenient from an engineering standpoint. * UTC can get out of whack with the rotation of the earth around the sun, because our rotation is not uniform, but is calculated rather than measured (well, sort of) No its not about years, that's what February 29th is for, it's about days. As the Earth rotates (there's a rotation versus revolution nomenclature), the sun appears to move around it daily. This is the solar day. At a certain point, at a certain location, the sun is at the highest it will be in the sky for that rotation. This is solar noon. The time between two consecutive noons at any location is not constant mostly due to the Earth's orbit being elliptical and the tilt of the Earth's axis. But for any place on Earth, the mean solar day, the average of the solar day over the year, is the same. If the Earth was a solid sphere rotating at a constant speed, that would be the end of the story. But it's not and for a variety of reasons, the rotation of the Earth changes with time (mostly slows). This causes the mean solar day to get longer. * UTC is TAI plus leap seconds. In 1972, when leap seconds were first introduced, UTC was TAI - 10 seconds. UTC is now TAI - 34 seconds. TAI ticks exactly as fast as UTC, ignoring leap second adjustments. * UTC is slower than UT1 by about 1ms per day. That's a very tricky sentence. I think that the mean solar day right now is about 86400.002 s long. The mean solar day was actually exactly 86400 s long sometime around 1820. * On 12/31/2008 UTC was (-) 591.8ms behind UT1. On 1/1/2008 UTC was 407.1ms ahead of UT1. * Leap seconds are applied to UTC every few years to remain in line with UT1, the time based on the rotation of the earth around the sun. A time based on the rotation of the Earth.(period) As mentioned above, it doesn't really have anything directly to do with Earth's location in its orbit. * GMT is used to imply UT1, but sometimes UTC, but really GMT is just massively confusing and you shouldn't use it, either in conversation or in your servers/routers, because nobody is really sure without reading a lot of documentation what GMT means for each manufacturer/OS/software. * When writing code regarding dates and times, know that any year may have 366 days, and any minute may have 61 seconds. Also remember that an administrator or automated clock recalibration may take you forward or back in time any arbitrary amount. * When in doubt, Dr. Daniel Gambis is always right. Very, very few should not defer to his judgement on such matters.
Re: Security team successfully cracks SSL using 200 PS3's and MD5
On 01/05/09 12:47, Randy Bush wrote: perhaps i am a bit slow. but could someone explain to me how trust in dns data transfers to trust in an http partner and other uses to which ssl is put? Because I have to trust the DNS anyway. If the DNS redirects my users to a bad site, they may not notice that they are actually entering their personal information into the perfectly-SSL-secured www.bankofamerca.com. Given the willingness of some CAs (which are trusted by browsers) to give out certs with no verification at all[1], I am not sure there is much to be trusted in the current CA-cartel arrangement, with the exception of EV certs. So banks can continue to use the equivalent of EV certs, and the rest of us who don't need an extra layer of trust can switch to using root certs in the DNS secured via DNSSEC. The trust hierarchy is already there. I agree that there are two different trust models, one of which I am required to trust and the other of which I don't trust at all. michael [1]http://www.theregister.co.uk/2008/12/29/ca_mozzilla_cert_snaf/
Re: Security team successfully cracks SSL using 200 PS3's and MD5
On Tue, Jan 06, 2009 at 06:09:34 +0900, Randy Bush wrote: to use your example, the contractor who serves dns for www.bank.example could insert a cert and then fake the web site having (a child of) that cert. whereas, if the site had its cert a descendant of the ca for all banks, this attack would fail. To be pedantic, it'd have to be the contractor who holds the signing key for the bank.example zone (which may be a separate entity from whoever has operational control of the nameservers). You're correct that this proposal treats control of a DNS zone as a strong proof of identity, but I'd argue that that's the case already -- whoever controls the zone can easily get a CA to issue them a cert which is valid for the host www.bank.example. Whether the organization name is Example Bancorp or DomainSquatters'R'Us, Inc. is irrelevant, since nobody ever looks at that. I'd go so far as to argue that the hostname is the proper *definition* of identity in this context. The client identifies the destination it wishes to connect to by hostname, not by organization name. The purpose of the cert ought to be to ensure that we're talking to the host identified by that hostname (according to a necessarily trusted DNS). Ensuring that the hostname belongs to someone the user really wants to speak to is an orthogonal problem which is impossible to solve without a clueful user in the loop, and at which the current model is failing miserably.
Re: Security team successfully cracks SSL using 200 PS3's and MD5
In message 20090105201859.gc15...@ferrum.uhlenkott.net, Jason Uhlenkott write s: On Fri, Jan 02, 2009 at 15:33:05 -0600, Joe Greco wrote: This would seem to point out some critical shortcomings in the current SSL system; these shortcomings are not necessarily technological, but rather social/psychological. We need the ability for Tom, Dick, or Harry to be able to crank out a SSL cert with a minimum of fuss or cost; having to learn the complexities of SSL is itself a fuss which has significantly and negatively impacted Internet security. Somehow, we managed to figure out how to do this with PGP and keysigning, but it all fell apart (I can hear the it doesn't scale already) with SSL. If we had DNSSEC, we could do away with SSL CAs entirely. The owner of each domain or host could publish a self-signed cert in a TXT RR, and the DNS chain of trust would be the only form of validation needed. Or one could use the CERT to publish a cert :-) Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
Re: Ethical DDoS drone network
BATTLES, TIMOTHY A (TIM), ATTLABS wrote: True, real world events differ, but so do denial of service attacks. Distribution in the network, PPS, BPS, Packet Type, Packet Size, etc.. Etc.. Etc.. So really I don't get the point either in staging a real life do it yourself test. So, you put pieces of your network in jeopardy night after night during maintenance windows to determine if what?? Your vulnerable to DDOS? We all know we are, it's just a question of what type and how much right? So we identify our choke points. We all snip packet types. What I don't get is what you would be doing trying to accomplish this on a production network. Worse case is you break something. Best case is you don't. So if best case scenario is reach, what have you learned? Nothing! So what do you do next ramp it up? Seems silly. I'll personally agree with you, though there are fringe cases. For example, one or more of your peers might falter before you do. While I'm sure they won't enjoy you hurting their other customers, knowing that your peer's router is going to crater before your expensive piece of hardware is usually good knowledge. Since it's controlled, you can minimize the damage of testing that fact. Another test is automatic measures and how well they perform. This may or may not be useful in a closed environment, though in a closed environment, they'll definitely need to mirror the production environment depending on what criteria they use for automatic measures. A non-forging botnet which sends packets (valid or malformed) to an accepting recipient is strictly another internet app, and has a harm ratio related to some p2p apps. IP forging, of course, could cause unintended blowback, which could have severe legal ramifications. That being said, I'd quit calling it a botnet. I'd call it a distributed application that stress tests DDoS protection measures, and it's advisable to let your direct peers know when you plan to run it. They might even be interested in monitoring their equipment (or tell you up front that you'll crater their equipment). Jack
Re: Leap second tonight
Peter Beckman wrote: * GMT is used to imply UT1, but sometimes UTC, but really GMT is just massively confusing and you shouldn't use it, either in conversation or in your servers/routers, because nobody is really sure without reading a lot of documentation what GMT means for each manufacturer/OS/software. WET/WEST is a little more precise and less confusing than GMT/BST (or IST if you're of a more celtic nature, although this confuses people living on the Indian subcontinent) although in tz-land, GMT has a specific and pretty consistent definition. But it is generally a bad idea to use it. People get confused. * When writing code regarding dates and times, know that any year may have 366 days, and any minute may have 61 seconds. Or 59 seconds in the case of a negative leap second. Nick
RE: Ethical DDoS drone network
In my opinion, the real thing you can puzzle out of this kind of testing is the occasional hidden dependency. I've seen ultra-robust servers fail because a performance monitoring application living on them was timing out in a remote query, and I've also seen devices fail well below their expected load because they were using multiple layers of encapsulation (IP over MPLS over IP over Ethernet over MPLS over Frame-Relay ...) and one of the hidden middle-layers was badly optimized. The advantage of performing this DDoS-style load testing on yourself is that *you can turn it off once you experience the failure* and then go figure out why it broke when it did. This is a lot more pleasant than trying to figure it out at 2:30 in the morning with insufficient coffee. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com --- On Mon, 1/5/09, BATTLES, TIMOTHY A (TIM), ATTLABS tmbatt...@att.com wrote: From: BATTLES, TIMOTHY A (TIM), ATTLABS tmbatt...@att.com Subject: RE: Ethical DDoS drone network To: Edward B. DREGER eddy+public+s...@noc.everquick.net, na...@merit.edu Date: Monday, January 5, 2009, 4:16 PM True, real world events differ, but so do denial of service attacks. Distribution in the network, PPS, BPS, Packet Type, Packet Size, etc.. Etc.. Etc.. So really I don't get the point either in staging a real life do it yourself test. So, you put pieces of your network in jeopardy night after night during maintenance windows to determine if what?? Your vulnerable to DDOS? We all know we are, it's just a question of what type and how much right? So we identify our choke points. We all know them. We look at the vendor data on how much PPS it can handle and quickly dismiss that. So what's the next step? Put the device that IS the choke point and pump it full of all different flavors until it fails. No harm no foul an now we have data regarding how much and what takes the device out. If the network is scaled, well we now know that we have x amount of devices that can fail if the DDOS goes X PPS with Y packet types. What I don't get is what you would be doing trying to accomplish this on a production network. Worse case is you break something. Best case is you don't. So if best case scenario is reach, what have you learned? Nothing! So what do you do next ramp it up? Seems silly. -Original Message- From: Edward B. DREGER [mailto:eddy+public+s...@noc.everquick.net] Sent: Monday, January 05, 2009 12:03 PM To: na...@merit.edu Subject: RE: Ethical DDoS drone network TAB Date: Mon, 5 Jan 2009 11:54:06 -0500 TAB From: BATTLES, TIMOTHY A (TIM), ATTLABS TAB assuming your somewhat scaled, I would think this could all be done TAB in the lab. And end up with a network that works in the lab. :-) - bw * delay - effects of flow caching, where applicable - jitter (esp. under load) - packet dups and loss (esp. under load) - packet reordering and assiciated side-effects - upstream/sidestream throughput (esp. under load) No, reality is far more complex. Some things do not lend themselves to _a priori_ models, nor even TFAR generalizations. 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: dav...@brics.com -*- jfconmaa...@intc.net -*- s...@everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Ethical DDoS drone network
On Jan 6, 2009, at 6:52 AM, Jack Bates wrote: (or tell you up front that you'll crater their equipment). This is the AUP danger to which I was referring earlier. Also, note that the miscreants will attack intermediate systems such as routers they identify via tracerouting from multiple points to the victim - there's no way to test that externally without violating AUPs and/or various criminal statutes in multiple jurisdictions. And then there are managed-CPE and hosting scenarios, which complicate matters further. Tim's comments about understanding the performance envelopes of all the system/infrastructure elements are spot-on - that's a primary input into design criteria (or should be). With this knowledge in hand, one can test the most important things internally. But prior to testing, one should ensure that the architecture and the element configurations are hardened with all the relevant BCPs, and scaled for capacity. The main purpose of the testing would be to verify correct implementation and ensure all the failure modes have been accounted for and ameliorated to the degree possible, and also as an opsec drill. What I've seen over and over again is a desire to test because it's 'cool', but no desire to spend the time in the design and implementation (or re-implementation) phases to ensure that things are hardened in the first place, nor to spell out security policies and procedures, train, etc. Actual *security* (as opposed to checklisting) consists of attention to lots of tedious details, drudgery and scut-work, involving the coordination of multiple groups and the attendant politics. It isn't 'sexy', it isn't 'cool', it isn't 'fun', but it pays off at 4AM on a holiday weekend. Testing should become a priority only after one has done everything one knows to do within one's span of control, IMHO - and I've yet to run across this happy circumstance in any organization who've asked me about this kind testing, FWIW. --- Roland Dobbins rdobb...@cisco.com // +852.9133.2844 mobile All behavior is economic in motivation and/or consequence.
Re: Ethical DDoS drone network
On Jan 6, 2009, at 7:23 AM, David Barak wrote: In my opinion, the real thing you can puzzle out of this kind of testing is the occasional hidden dependency. Yes - but if your lab accurately reflects production, you can discover this kind of thing in the lab (and one ought to already have a lab setup which reflects production for many reasons having nothing to do with security). --- Roland Dobbins rdobb...@cisco.com // +852.9133.2844 mobile All behavior is economic in motivation and/or consequence.
Re: IPv6: IS-IS or OSPFv3
On Tuesday 06 January 2009 01:43:25 am Justin Shore wrote: I never could get IS-IS to work with multiple areas. The 7600s made a smelly mess on the CO floor every time I tried. In the end I went with a L2-only IS-IS network. How so? Cheers, Mark. signature.asc Description: This is a digitally signed message part.
Re: Leap second tonight
On Mon, Jan 5, 2009 at 4:19 PM, Peter Beckman beck...@angryox.com wrote: * UTC can get out of whack with the rotation of the earth around the sun, because our rotation is not uniform, but is calculated rather than measured (well, sort of) As Crist Clark points out, leap seconds are about the Earth's rotation about its own axis, not its revolution (orbit) around the sun. Atomic clocks are much more consistent and uniform than the Earth's rotation. If we don't correct for the differences somehow, eventually wall clock time would get out of sync with the day/night cycle. In $LARGE_NUMBER years, 1:00 PM would be in the middle of the night. Earth's orbit and the Julian calendar have the same problem, which is why we have leap days. Otherwise, the calendar would get out of sync with the seasons. * When writing code regarding dates and times, know that any year may have 366 days, and any minute may have 61 seconds. I wouldn't even define it that narrowly. We might end up with 62 or 63 or 57 seconds in a minute, or 364 or 367 days in a year. Internally, store everything using a fixed-unit offset (e.g., traditional Unix time, i.e., seconds from 1 Jan 1970). Use OS provided facilities to translate to and from human-friendly representations, and thus make it the OS's problem. (If the OS is your problem... sucks to be you. You'll need lots of tables of historic, idiosyncratic clock/calendar changes to get it right.) For program timers (timeouts, etc.), don't use wall clock time at all, since the wall clock may be wrong, and the admin may fix it, yielding time travel. Most OSes provide something like a seconds since boot value, which should always monotonically increase (unless you're running Windows 95, heh), regardless of what the admin is doing to confuse matters. From the other side of the coin: As an admin, avoid advancing the wall clock in large steps, or going backwards at all. If you must do either, do it in single-user mode, or whatever your platform's equivalent is. Don't assume the programmers got it right. Another programmer tip: When storing dates and times in a file, database, etc., and you have to care about multiple timezones: Store at least three of UTC, local time, calculated difference, logical local timezone. The extra information lets one figure out after-the-fact what the timezone tables on the system said when the user entered the information. When the gov'mint monkeys with the time zones, there's always a lag between official announcement and local implementation. Without knowing what the time zone tables said, it can be hard to know if you should apply a correction later. -- Ben
Re: Ethical DDoS drone network
-- On Mon, 1/5/09, Roland Dobbins rdobb...@cisco.com wrote: From: Roland Dobbins rdobb...@cisco.com Subject: Re: Ethical DDoS drone network To: NANOG list na...@merit.edu Date: Monday, January 5, 2009, 6:39 PM On Jan 6, 2009, at 7:23 AM, David Barak wrote: In my opinion, the real thing you can puzzle out of this kind of testing is the occasional hidden dependency. Yes - but if your lab accurately reflects production, you can discover this kind of thing in the lab (and one ought to already have a lab setup which reflects production for many reasons having nothing to do with security). I agree - having a lab of that type is absolutely ideal. However, the ideal and the real diverge tremendously in large and mid-size enterprise networks, because most enterprises just don't have enough lab equipment to adequately model all of the possible scenarios, and including the cost of a lab in the rollout immediately doubles all capital expenditures. The types of problems that the ultra-large DoS can ferret out are the kind which *don't* show up in anything smaller than a 1:1 or 1:2 scale model. Consider for a moment a large retail chain, with several hundred or a couple thousand locations. How big a lab should they have before deciding to roll out a new network something-or-other? Should their lab be 1:10 scale? A more realistic figure is that they'll consider themselves lucky to be between 1:50 and 1:100, and that lab is probably understaffed at best. Having a dedicated lab manager is often seen as an expensive luxury, and many businesses don't have the margin to support it. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
question about BGP default routing
Hi all I have a question:
I see very few prefixes in a routing table and combining the prefixes
does not cover addresses space, for example, {78.41.184.0/21,
91.103.239.0/24, 91.103.232.0/22, 82.138.64.0/23, 91.103.232.0/21,
77.95.71.0/24} are all prefixes I observed from a BGP speaking router,
I am just asking is this router using a default routing for all the
other destinations?
Thanks a lot
Re: question about BGP default routing
If it has a default route, 0.0.0.0/0, in its routing table, then yes,
it is.
If it does not, then no, it is not.
-jasper
On 6/01/2009, at 1:05 PM, Kai Chen wrote:
Hi all I have a question:
I see very few prefixes in a routing table and combining the prefixes
does not cover addresses space, for example, {78.41.184.0/21,
91.103.239.0/24, 91.103.232.0/22, 82.138.64.0/23, 91.103.232.0/21,
77.95.71.0/24} are all prefixes I observed from a BGP speaking router,
I am just asking is this router using a default routing for all the
other destinations?
Thanks a lot
--
Jasper Bryant-Greene
Network Engineer, Unleash
ddi: +64 3 978 1222
mob: +64 21 129 9458
Re: Ethical DDoS drone network
On Jan 6, 2009, at 8:01 AM, David Barak wrote: The types of problems that the ultra-large DoS can ferret out are the kind which *don't* show up in anything smaller than a 1:1 or 1:2 scale model. In my experience, once one has an understanding of the performance envelopes and has built a lab which contains examples of the functional elements of the system (network infrastructure, servers, apps, databases, clients, et. al.), one can extrapolate pretty accurately well out to orders of magnitude. The problem is that many organizations don't do the above prior to freezing the design and initiating deployment. --- Roland Dobbins rdobb...@cisco.com // +852.9133.2844 mobile All behavior is economic in motivation and/or consequence.
Re: Ethical DDoS drone network
Roland Dobbins wrote: In my experience, once one has an understanding of the performance envelopes and has built a lab which contains examples of the functional elements of the system (network infrastructure, servers, apps, databases, clients, et. al.), one can extrapolate pretty accurately well out to orders of magnitude. The problem is that many organizations don't do the above prior to freezing the design and initiating deployment. Sadly, I think money and time have a lot to do with this. Technology is a moving target, and everyone is constantly struggling to keep up while maintaining performance/security. I've seen this out of software developers, too. I'd say I've seen more outages due to a simple command typed into a router cli crashing the router than DDoS traffic. Perhaps I've been lucky with the latter. Jack
Where there's a nanog thread there'll be a vendor solution .. Re: Ethical DDoS drone network
On Mon, Jan 5, 2009 at 10:24 PM, BATTLES, TIMOTHY A (TIM), ATTLABS tmbatt...@att.com wrote: There are some assumptions here. First are you considering volumetric DDOS attacks? Second, if you plan on harvesting wild bots and using them to serve your purpose then I don't see how this can be ethical unless they are just clients from your own network making it less distributed. I cant believe this .. http://www.iprental.com Looks like anonymizer combined with what looks almost like a rent a botnet, legit nodes (you sign up to download a client that makes you part of this botnet, etc) http://www.iprental.com/technical/ Speaking of a commercial botnet, there was something similar earlier - but that was a download this bulk mailer type operation, guys called Atriks, who got tracked so extensively by spamhaus that they seem to have kind of disappeared now. --srs
generic attack on Cisco routers
http://www.theregister.co.uk/2009/01/05/cisco_router_hijacking/ --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: question about BGP default routing
KC Date: Mon, 5 Jan 2009 18:05:48 -0600 KC From: Kai Chen KC is this router using a default routing for all the other KC destinations? Either that: router sh ip route 0.0.0.0 Routing entry for 0.0.0.0/0, supernet or partial tables with no default: router sh ip route 0.0.0.0 % Network not in table is what you'd expect. 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: dav...@brics.com -*- jfconmaa...@intc.net -*- s...@everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: question about BGP default routing
Will this default route 0.0.0.0/0 be exporting to AS-level neighbors? On Mon, Jan 5, 2009 at 8:49 PM, Edward B. DREGER eddy+public+s...@noc.everquick.net wrote: KC Date: Mon, 5 Jan 2009 18:05:48 -0600 KC From: Kai Chen KC is this router using a default routing for all the other KC destinations? Either that: router sh ip route 0.0.0.0 Routing entry for 0.0.0.0/0, supernet or partial tables with no default: router sh ip route 0.0.0.0 % Network not in table is what you'd expect. 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: dav...@brics.com -*- jfconmaa...@intc.net -*- s...@everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
Re: Security team successfully cracks SSL using 200 PS3's and MD5
On 2009/01/05 10:47 PM Randy Bush wrote: perhaps i am a bit slow. but could someone explain to me how trust in dns data transfers to trust in an http partner and other uses to which ssl is put? I must also be slow. Can someone tell me how DNSSEC is supposed to encrypt my TCP/IP traffic?
Northern Ireland undersea branch to be implemented
Hibernia has been busy. THE COMMUNICATIONS minister Eamon Ryan and the North's Enterprise Minister Arlene Foster have announced the awarding of a £30 million (€32 million) contract to construct a new direct telecommunications link to North America that will benefit Northern Ireland and the Republic http://www.irishtimes.com/newspaper/finance/2009/0106/1230936699678.html -M -- Martin Hannigan mar...@theicelandguy.com p: +16178216079
Re: Where there's a nanog thread there'll be a vendor solution .. Re: Ethical DDoS drone network
This is new to you? Polymorphic anonymizers have been a way of life for a while now. Jeff On Mon, Jan 5, 2009 at 7:55 PM, Suresh Ramasubramanian ops.li...@gmail.com wrote: On Mon, Jan 5, 2009 at 10:24 PM, BATTLES, TIMOTHY A (TIM), ATTLABS tmbatt...@att.com wrote: There are some assumptions here. First are you considering volumetric DDOS attacks? Second, if you plan on harvesting wild bots and using them to serve your purpose then I don't see how this can be ethical unless they are just clients from your own network making it less distributed. I cant believe this .. http://www.iprental.com Looks like anonymizer combined with what looks almost like a rent a botnet, legit nodes (you sign up to download a client that makes you part of this botnet, etc) http://www.iprental.com/technical/ Speaking of a commercial botnet, there was something similar earlier - but that was a download this bulk mailer type operation, guys called Atriks, who got tracked so extensively by spamhaus that they seem to have kind of disappeared now. --srs -- Jeffrey Lyon, Leadership Team jeffrey.l...@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.
Hirschmann Switches?
I'm looking for feedback from users of the Hirschmann (Belden) ethernet switches in a service provider environment. Private or public appreciated. Drive Slow, Paul Wall
Re: Where there's a nanog thread there'll be a vendor solution .. Re: Ethical DDoS drone network
I cant believe this .. http://www.iprental.com sheesh! and i thought the rirs had a monopoly on ip address rental. :) randy
DNSSEC vs. X509 (Re: Security team successfully cracks SSL...)
Joe Abley jab...@hopcount.ca writes: On 2009-01-05, at 15:18, Jason Uhlenkott wrote: If we had DNSSEC, we could do away with SSL CAs entirely. The owner of each domain or host could publish a self-signed cert in a TXT RR, ... or even in a CERT RR, as I heard various clever people talking about in some virtual hallway the other day. http://www.isi.edu/in-notes/rfc2538.txt. i wasn't clever but i was in that hallway. it's more complicated than RFC 2538, but there does seem to be a way forward involving SSL/TLS (to get channel encryption) but where a self-signed key could be verified using a CERT RR (to get endpoint identity authentication). the attacks recently have been against MD5 (used by some X.509 CA's) and against an X.509 CA's identity verification methods (used at certificate granting time). no recent attack has shaken my confidence in SSL/TLS negotiation or encryption, but frankly i'm a little worried about nondeployability of X.509 now that i see what the CA's are doing operationally when they start to feel margin pressure and need to keep volume up + costs down. i don't have a specific proposal. (yet.) but i'm investigating, and i recommend others do likewise. -- Paul Vixie
Re: Northern Ireland undersea branch to be implemented
Martin Hannigan wrote: Hibernia has been busy. THE COMMUNICATIONS minister Eamon Ryan and the North's Enterprise Minister Arlene Foster have announced the awarding of a £30 million (€32 million) contract to construct a new direct telecommunications link to North America that will benefit Northern Ireland and the Republic http://www.irishtimes.com/newspaper/finance/2009/0106/1230936699678.html That's just a spur from the existing Hibernia Atlantic fibre that goes from Halifax to Dublin. In my opinion, that should have been done from the very beginning. Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobal an Iarthar http://www.airwire.ie Phone: 091-865 968
Re: Security team successfully cracks SSL using 200 PS3's and MD5
In message 4962e096.7070...@karnaugh.za.net, Colin Alston writes: On 2009/01/05 10:47 PM Randy Bush wrote: perhaps i am a bit slow. but could someone explain to me how trust in dns data transfers to trust in an http partner and other uses to which ssl is put? I must also be slow. Can someone tell me how DNSSEC is supposed to encrypt my TCP/IP traffic? DNSSEC allows you to go from dns name - CERT in a secure manner. The application then checks that the cert used to establish the ssl session is one from the CERT RRset. Basically when you pay your $70 or whatever for the CERT record you are asking the CA to assert that you have the right to use the domain name. It's expensive because they are not part of existing DNS trust relationship setup when the domain was delegated in the first place. The natural place to look for DNS trust is in the DNS. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
Re: Where there's a nanog thread there'll be a vendor solution ..Re: Ethical DDoS drone network
- Original Message - From: Randy Bush Sent: Monday, January 05, 2009 7:30 PM Subject: Re: Where there's a nanog thread there'll be a vendor solution ..Re: Ethical DDoS drone network I cant believe this .. http://www.iprental.com sheesh! and i thought the rirs had a monopoly on ip address rental. :) randy I watched the 'Demo Video' and the addresses shown were from ATT and Comcast space. Any idea of what space they might be from in real life or is that part of their secret sauce? Thanks, --Michael
Re: Where there's a nanog thread there'll be a vendor solution ..Re: Ethical DDoS drone network
On Tue, Jan 6, 2009 at 12:52 PM, Michael Painter tvhaw...@shaka.com wrote: I watched the 'Demo Video' and the addresses shown were from ATT and Comcast space. Any idea of what space they might be from in real life or is that part of their secret sauce? J.Random ADSL / cable space I dare say. Though what said cable / adsl SPs would have to say about reselling of service is an AUP violation is anybody's guess :) --srs -- Suresh Ramasubramanian (ops.li...@gmail.com)
