We come in peace!

We come in peace!

By: David Connors
Date: 16 August 2010 | Category: Uncategorized, planning, setup, tech•ed 2010 | Tags:

Your friendly technology team

Thank you to everyone for the kind feedback on our recent BIGAU presentation both at and after the event. I couldn’t resist including this picture again as a) I love it, and b) it was the only politically correct on in the slide deck (sorry Princess Parker!).

We’re on site now and work has begun in earnest on provisioning the infrastructure for the event. Jorke and Ben are still in Brisbane busily setting up all of the HP blades for DemoNet and these will ship down to the venue on Wednesday.

Pile of work

We’re going to try and keep the blog up to date as we build out the network infrastructure – but as always, delivery of the event will take priority.

If you have any cool ideas for topics you would like to see covered on the blog, post a comment at the end of this article and we’ll see what we can whip up in response.
Share and Enjoy:

4 Responses to “We come in peace!”

Nigel Wadsworth 10/08/16 19:43

Wouldn’t mind some shiny Visio or high level pictures of the interconnects or layouts?
Lachlan B 10/08/28 13:27

Hi David – I was at your two talks, TechEd backstage and Philosphy of software development – both were great! I’m a .net developer so it was really interesting hearing from someone who knows so much about the hardware and software side of things. And BTW, great job in keeping everything up and not murdering anyone due to lack of sleep.

So, here’s a few questions for you.

1 – Why was the wireless network not encrypted? (My stupid guess, too much server CPU overhead?)

2 – Why was the SSID broadcasted? Wouldn’t it be safer to not broadcast it? (stupid guess: it doesn’t make any difference to the wireless network security because it’s trivial to figure it out anyway, and maybe it makes things easier for everyone)

3 – What things do you think developers need to do to prepare for IPv6? Having been a programmer for 10 years I can definitely confirm your fears that it’s just not an issue that programmers think about. I’ve never even considered it on any project that I’ve been on (don’t kill me)
David Connors 10/08/29 09:29

@Lachlan B – Thanks for the positive feedback.

I’m delighted to hear that you enjoyed ARC301. It was always a huge risk as almost all of the content was polarising. The session REALLY devided the audience and that shows through in the comments. A small number of people HATED it with a passon (2-5% .. which is enough to completely stuff the session score), but the rest were really happy and supportive. A few people said the session should have been 2 hrs long and others definitely want more of the same back next year. Pobar spends a lot of time on the event floor (Microsoft lock me in a cupboard mostly, for good reason) and mentioned that a lot of people approached him and thanked him for ARC301 mostly because we laid it on the line and said a lot of things everyone thinks but no one is confident enough to say. Re the couple of cranky units: The real piss funny part (I am still chuckling about it) was an evalution note saying “I am pretty sure the fat one was drunk”. Comedy GOLD – absolute cracker!

Anyway, to answer your questions:

1. Nothing to do with server load. The network is unencrypted because we have to balance usability against security. There are three “buckets” you can put wireless networks in to: 1) Unsecured as per TechEd. 2) “Personal” security such as WPA2-Personal. These operate using pre-shared keys on both ends and 3) “Enterprise” security with asymmetric encryption.

When you give out a pre-shared key to 3500 people, 1 & 2 are pretty much identical. Option 3 is a logistic nightmare for 3500 people for 3.5 days.

We’re pretty upfront about the choice in the conference guide. If you need to do anything secure, it should be over a VPN or TLS technology like SSL anyway.

2. Correct, it makes SFA difference to security. If the SSID is hidden then any prospective client sends a probe request to ask “Do you provide SSID SuperSecret?” and all stations in range will respond. Any h4x0r just sniffs this off the air and that is easy to do as clients are joining and leaving all the time. One outcome I CAN guarantee about hiding it is that the help desk would be pretty busy.

3. In preparing for IPv6, there are a couple of different scenarios. If you’re writing a sockets-based application like an SSH client or a web server then you need to be on top of it immediately or you will piss your customers off. The version of SecureCRT I use (damned expensive SSH client that has flawless VT100 emulation) does not support IPv6 address entry. They might have a version that does now but realistically they should have been there 2-3 years ago given their target audience. The work is pretty obvious (don’t assume 32-bit dotted notation in the UI), infer the address family from the address entered by the client, and so on. This is probably the rarer scenario.

The second scenario involves applications that use IP address data but not necessarily sockets. In this case, you might have a web application that reads information about out of the raw HTTP request for logging or access control etc. If you work at an ISP you might process net flows for client billing and so on. In this case, you have a big dependency IP address related information. I reckon there are a zillion of these scenarios out there and people are not really thinking about it.

To be honest, I had no idea how well received VOC208 would be – big room and STILL standing room only. I can’t believe how well it rated given how poorly prepared we were due to bump out issues. I think next year we’ll do the same again, and I might put my software engineer hat on briefly to show code examples and so on.

Thanks again for the positive feedback – it was really encouraging.