Apropos to my interests and as the namesake of this blog, I needed to pass along this presentation from Martin Levy of Hurricane Electric. Levy talks about his ixp-jumboframes-00 RFP draft advocating for ISPs and other organizations that peer with each other at NAPs and IXPs to up the MTU on these links to 9000 from the standard 1500.  

There is absolutely nothing extraordinary about his proposal- the idea is simple, really. Customers of ISPs want larger payloads to facilitate data replication and application delivery. Most ISPs are willing to provide it (after all, they're usually making money on a per Mb basis, aren't they?) but IXPs really won't make the necessary changes on their switching infrastructure because there isn't a standard method, name or even size for doing it. So, Levy just proposed it:

Jumbo Frames = 9000 bytes. Period. 

As a customer doing gigabytes of global data replication on a nightly basis, I'm fully in support of this initiative and thought that a little extra internet PR for this RFP couldn't hurt.  I do wonder what the IEEE (as official maintainers of all things Ethernet) have to say about the IETF proposing such a standard.

Like any job, working in IT has glorious peaks and desolate valleys. Last weekend, I unwittingly strolled into death valley and emerged 20+ hours later dehydrated, delirious, and otherwise damaged. What was supposed to have been a routine data center power outage turned into a weekend-long power struggle against bad configurations, failed hardware and ill-health. So now that I've survived my excursion into the pit of hell, I thought it might be therapeutic to do some sort of electronic memorial for my weekend, dead and gone. So, without further ado, I present to the...

Read the rest of this post »

RIPE recently posted a great presentation by Geoff Huston about IPv6 dual stack performance that was recapped at MENOG by Philip Smith of APNIC. In the presentation, Geoff goes through some of the more recent implementations of Happy Eyeballs dual stack behaviors across a number of operating systems and browsers. He also breaks down some of his recent research into IPv6 reliability by country and technology (6to4, Teredo, Native). The results of his research are to say the least, alarming. 

Yup, you're reading that right. About a 40% IPv6 failure rate from the end-user perspective.

What's most alarming for me is that over the last week, I've listened to presentation after presentation talking about how absolutely easy it is to deploy IPv6 in networks. And admittedly, it is. Simultaneously, I've been keeping up on flame after sorry flame on the NANOG mailing list directed at some poor guy who accidentally enabled IPv6 on his network without disabling RAs, causing his network to go haywire. The basic gist was "Don't be an idiot, set up IPv6 properly, and do it NOW."

Geoff's research basically puts the brakes on all of that. It's not that he's saying that IPv6 is bad or it shouldn't be deployed, but he raises some serious issues related to end-user performance that should make any enterprise network administrator think twice about globally enabling IPv6. Until some of these problems get sorted, I know I'll be looking for ways to add it to our core and enable IP transit, but keeping it from our user nets.

You can read Geoff's presentation here. 

I've been using Skype for work meetings since at least 2005 and amassed a ton of great etiquette tips. You could call me a master. Here's a simple breakdown I've developed of how to not be a complete tool while working with me (or anyone else for that matter) on Skype. 

5. Using a wireless handset while doing things around the house. Perhaps this is akin to taking a phone call while you're out to dinner with a loved one: For the love of God, concentrate on what's important. You aren't on the call so that everyone can  listen in while you brew tea, let the dog out, get dressed, cook sausages, pee, or whatever. You're on the call for only two possible reasons: to listen or to talk. If the call really doesn't have anything to do with you but you can't bow out politely, then stick your mic on mute and get on with it. 

4.  Not staying current on your Skype updates. Ever been on a call and all set to add in a 3rd party, only to find that as soon as you add the caller, the connection to them drops without even ringing them? It's probably because they aren't up to date on their Skype updates or (even worse), you aren't. Skype rolls out features and improvements constantly, but many features drop back to the lowest level of code running on the call. Do yourself (and everyone a favor) by keeping up to date.

3. Typing loudly onto the call. Yeah, it's really convenient to be plugged in on a project, hacking away at your code or notes while the project call is taking place. Embrace that productivity, I say! But please, enjoy it responsibly. Since microphones on laptops are often placed nearby the keyboard, type softly. Or better yet, wear a headset with a microphone away from your keyboard. If you must take a call without a microphone headset, simply muting the call when you're not speaking is another great way to work around this. 

1. Taking multi-party voice calls over 3G networks using your mobile phone or iPad. This offense has been given the special honor of worst thing you can do on Skype due to a series of conference calls I've been on over the last year where the project manager has decided to run the call from his car during his morning commute to work. The rest of us are comfortably seated in our offices or homes around the global, connecting via high-speed broadband or enterprise networks, and enjoying crystal-clear reception while we get work done. When he jumps on the call, all productivity is out the window while his garbled, chopped and tinny voice intersperses with a rage-inducing cacophony of honking horns and white noise. Do all of us a favor and schedule yourself so that you can take these calls from your desk and reserve 3G Skype for emergencies, or better yet, wait for true 4G ubiquity before pulling this stunt. 

In leiu of actually creating new content this week, I've decided to post something that is both heartwarming and totally geeky. Enjoy. 

I’ve just spent the last two hours trying a million different combinations of ldapsearch queries, trying to get the syntax just right so I can pass on the correct parameters to our web developers. Each and every time, I got the same damned error:

ldap_bind: Invalid credentials (49)

additional info: 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 52e, vece

I finally found the problem. It was of course, a stupid one. Here’s my incorrect query:

[dgr790@linux1 ~]$ldapsearch -E pr=200/noprompt -x -h dc.example.com \
-D CN=ServiceAccount,OU=Service Accounts,OU=User Accounts,DC=example,DC=com \
-w password -b DC=example,DC=com 
ldap_bind: Invalid credentials (49) 
additional info: 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 52e, vece

Now the correct syntax:

[dgr790@linux1 ~]$ ldapsearch -E pr=200/noprompt -x -h dc.example.com \
-D 'CN=ServiceAccount,OU=Service Accounts,OU=User Accounts,DC=example,DC=com'\
-w password -b DC=example,DC=com 
# extended LDIF 
# 
# LDAPv3 
# base with scope subtree 
# requesting: ALL 
# with pagedResults control: size=200 
# ... 
... 
...

Can you see the difference? I surely could not.

Hint. It’s the f*$#ing ‘quotes’ around the DN string. I want my hours back. At least this won’t happen again.

Late last night, a friend pointed me at the Qatar Ministry of Education website, noting that it had been h4x0r3d nicely. Indeed it had:

A super-quick overview of SkipFish

Skipfish is a free, fully-automated web application security scanner that is extremely easy to set up and use, even for novices with a tiny morsel of Linux know-how. What makes Skipfish unique is that it’s blazing fast, while still hiting upon quite an impressive laundry list of common web programming security mistakes, and some more exotic species of bugs.

This guide is meant as a super-quick get started guide and when I have a few minutes, I’ll add a follow-up on interpreting some of the Skipfish results.

(Official install docs are at http://code.google.com/p/skipfish/wiki/SkipfishDoc)

First, install pre-requisites:

# yum install openssl-devel libidn libidn-devel

Get and install skipfish

$ wget http://skipfish.googlecode.com/files/skipfish-2.00b.tgz
$ tar -zxf ./skipfish-2.00b.tgz 
$ cd skipfish-2.00b
$ make
cc -L/usr/local/lib/ -L/opt/local/lib skipfish.c -o skipfish -O3 -Wno-format -Wall 
-funsigned-char -g -ggdb -I/usr/local/include/ -I/opt/local/include/  -DVERSION=\"2.00b\" 
http_client.c database.c crawler.c analysis.c report.c -lcrypto -lssl -lidn -lz analysis.c: 
In function ‘get_date’: analysis.c:1389: warning: dereferencing type-punned pointer will break 
strict-aliasing rules analysis.c:1390: warning: dereferencing type-punned pointer will break 
strict-aliasing rules analysis.c:1391: warning: dereferencing type-punned pointer will break 
strict-aliasing rules   See dictionaries/README-FIRST to pick a dictionary for the tool.    

Having problems with your scans? Be sure to visit: http://code.google.com/p/skipfish/wiki/KnownIssues

Using Skipfish

First, copy the complete.wl dictionary file to a test-specific wordlist to use. The reason you want to do this is that skipfish will modify the wordlist on a site-specific basis, and you probably want to preserve your original file for the next time you run against a new site.

$ cp dictionaries/complete.wl ./testsite.wl
$ cp dictionaries/skipfish.wl .

Next, make an output directory for the site you intend to scan

$ mkdir testsite

Now, let’s let it rip:

$ ./skipfish -o ./testsite http://test.testsite.com/

Welcome to skipfish. Here are some useful tips:

1) To abort the scan at any time, press Ctrl-C. A partial report will be written
   to the specified location. To view a list of currently scanned URLs, you can
   press space at any time during the scan.

2) Watch the number requests per second shown on the main screen. If this figure
drops below 100-200, the scan will likely take a very long time.
3) The scanner does not auto-limit the scope of the scan; on complex sites, you
may need to specify locations to exclude, or limit brute-force steps.
4) There are several new releases of the scanner every month. If you run into
trouble, check for a newer version first, let the author know next.

More info: http://code.google.com/p/skipfish/wiki/KnownIssues

NOTE: The scanner is currently configured for directory brute-force attacks,
and will make about 231655 requests per every fuzzable location. If this is
not what you wanted, stop now and consult the documentation.

skipfish version 2.00b by 

- test.testsite.com -

Scan statistics:

    Scan time : 0:00:35.337
    HTTP requests : 345 (13.4/s), 500 kB in, 86 kB out (16.6 kB/s)  
    Compression : 354 kB in, 1671 kB out (65.0% gain)    
    HTTP faults : 0 net errors, 0 proto errors, 0 retried, 0 drops
    TCP handshakes : 355 total (3.8 req/conn)  
    TCP faults : 0 failures, 0 timeouts, 0 purged
    External links : 40 skipped
    Reqs pending : 992        

Database statistics:
    Pivots : 226 total, 1 done (0.44%)    
In progress : 154 pending, 64 init, 7 attacks, 0 dict    
    Missing nodes : 1 spotted
    Node types : 1 serv, 37 dir, 2 file, 4 pinfo, 139 unkn, 43 par, 0 val
Issues found : 17 info, 2 warn, 16 low, 6 medium, 2 high impact
    Dict size : 2335 words (170 new), 110 extensions, 256 candidates

http://latimesblogs.latimes.com/technology/2011/11/lightest-material-on-earth.html?track=lat-pick