October 2012 Archives

Everything's fine nothing to see here

Sandy ended up being less of an impact than we were fearing, which is always good. I suffered an 11 hour power outage at home, but I had internet when it came back. Most of the DC area people in our company were lightly struck, a few power outages, one tree-on-internet, but otherwise in good shape. We'll all likely be in the office tomorrow.

Big-ass storm preparations

| 1 Comment
As of the latest guidance, Hurricane Sandy is not likely to directly cross the DC area.

That said, hurricanes are pretty large storms so it's likely we'll catch a piece of it. How much of it is unknown at this time, but I will be keeping a real close eye on it.

That said, there are some preparations to be made.

The biggest storm we've handled recently was that Derecho storm back in late June that left me without power for three long, long days. That storm came with hurricane force winds and according to the power companies was the biggest ever power-wrecking weather system to come through that wasn't a hurricane, and even beat out some hurricanes. So we've been though this.

From experience, our primary systems are hosted in a first tier datacenter in Ashburn VA, there is little threat to our line-of-business online presence short of a direct hit. Freak accidents happen of course, but there isn't much you can do to plan for stuff thats outside of your domain of control.

But there is one thing that we do need to be prepared for:

Our on-call personnel being without power.

That's right, a people-problem. We have non-customer-visible systems that need tending, and if their designated sheepdog can't get to the machine flock there can be problems. What this means is that the people managing the on-call schedules need to pick alternates in case the primary is out of power, preferably a good list of alternates, and have a way of notifying them that they're up.

We have the benefit of a distributed workforce, so we have people who can be on call that are outside of the threat zone. This is something we have, but perhaps you may not. This is one more thing to put on that disaster-preparation checklist.
Systemic sexism is sneaky: you don't always recognize it when you see it, and unless you've had cause to be sensitized by it, you may not recognize when you see it until much after the fact. I had a moment of that when I read this blog-comment on a post covering swag at the Grace Hopper conference. The key quote:

But more seriously, I feel that one of the messages we give girls loud and clear in engineering is that they belong so long as they don't do anything obviously labelled as feminine -- the following things are not done by engineers: wear pink, wearing nail polish, caring about fashion, high heels, carrying a mirror in your purse, sewing things, worrying about walking in the dark.

But its ok for engineers of both genders to do all the things previously labelled as masculine, including: wearing blue, being a fan of men's football and hockey (where grown men beat each other up), drinking beer (and getting drunk), taking a group to play lasertag or paintball (i.e. simulated war), buying big electronics for our offices (beats conserving energy), loving cars and fighter jets, wearing male-sized Tshirts and so on. Now we just relabel all of this as gender-neutral and then on average men have to do nothing at all to fit into the mold of an engineer.

What this triggered was a crystallizing of an idea I had back after the LISA 2011 Women in Tech panel. Which I apparently didn't blog about here, which surprises me (have a link or two elsewhere). During that very excellent panel, one of the topics that got brought up was fitting into a very masculine office-culture. There are a variety ways to do that if you're not of the masculine persuasion, used strategies included embracing your exceptionalism ("I am the only Woman here, and this makes me special"), consciously excluding girly things to better fit in ("I'm just one of the guys, no need to panic"), and stone-headedly ignoring it all together ("I am me, deal with it."). Each of these has their own side-effects when the second and third woman shows up, but I'm getting ahead of myself.

How this blog comment ties into that observation from last year is the message employers give when:

  • Their job-posting (or company web-site) proudly claims that good cultural fit is just as important as ability to do the work.
  • When the interviewee gets to the interview, finds out the office is entirely male. Or maybe has a single woman in the office.

The message being given to prospective employees, and prospective employees good enough to at least get past the phone interview stage, is  you will have to fit into a very masculine culture if you want to work here, and fit in well. To someone who hasn't picked the I'm-just-one-of-the-guys survival strategy, this is off-putting. Meanwhile, the company in question wonders why they can't attract more female technical staff.

That LISA 2011 panel spent a lot of time on ways employers make the hiring process sexist, and this particular method didn't come up. I really should have noticed it earlier as I have friends who have complained about getting to the later stages of an interesting job interview process before realizing that the corporate culture was going to be too much effort to put up with.

The take-away here is:

Advertising good cultural fit as just as important as (or more important than) technical ability tells prospective employees, we like the cultural mix we have now and are looking for similar people. When that culture contains nothing but a single group (straight, westernized men, for instance), this is an exclusive hiring practice.

Improving gender-balance at LISA

LISA is offering grants for women to come attend the LISA 2012 conference this year. This is a Good Thing.

There are many reasons why the gender balance at conferences such as these is skewed so heavily male. Part of it is the gender balance in the profession is skewed. But it is also greatly assisted by a lower conference attendance rate by women. These grants are helping address the later point.

These grants should help LISA draw from the wider pool of potential attendees in the, "I'd love to go but there is no office budget for training this year" pool. I was in that very pool until I changed jobs, and from what I hear had I stayed I'd still be in that pool.

Hooray for them!

So why DO VPN clients use UDP?

I've wondered why IPSec VPNs do that for a while, but hadn't taken the time to figure out why that is. I recently took the time.

The major reason comes down to one very big problem: NAT traversal.

When IPSec VPNs came out originally, I remember there being many problems with the NAT gateways most houses (and hotels) had. It eventually cleared up but I didn't pay attention; it wasn't a problem that was in my area of responsibility, so I didn't do any troubleshooting for it.

There are three problems IPSec VPNs encounter with NAT gateways. One is intrinsic to NAT, the other two are specific to some implementations of NAT.

  1. IPv4 IPSec traffic uses IP Protocol 50, which is neither TCP (proto 6) or UDP (proto 17), and protocol 50 uses no ports on the packet. Therefore, a VPN concentrator can only support a single VPN client behind a specific NAT gateway. This can be a problem if four people from the same company are staying in the same hotel for a conference.
  2. IPv4 IPSec traffic uses IP Protocol 50, which is neither TCP or UDP. Some NAT gateways drop anything that isn't TCP or UDP, which will be a problem for IPSec VPNs.
  3. NAT gateways rewrite certain headers and play games with packet checksums, which IPSec doesn't like. So if IPSec is going to tunnel via TCP or UDP, there will be issues.

These are some of the reasons SSL VPNs became popular.

This is where RFC 3751 comes in. It's titled, "IPsec-Network Address Translation (NAT) Compatibility Requirements" oddly enough. It turns out that packet checksums are not required for IPv4 UDP packets, which makes them a natural choice to tunnel an IPSec VPN through a stupid NAT gateway. The VPN concentrator pulls the IPSec packet out of the UDP packet, and thanks to the cryptographic nature of IPSec it already has ways to detect packet corruption and will handle that (and any required retransmits) at the IPSec layer.