Posts Tagged ‘nanog’

The age old lie told by ISP support desks: ” The Internet is down,” was briefly reality again yesterday.

The past couple of days I’d been seeing and hearing comments that there was a disturbance in the force of the Internet. Initially a NANOG message was posted about a general malaise or instability in the Internet, some humorous quips were posted in response and the matter was soon forgotten.

A network operator looking with hindsight said that they had been able to see more than normal numbers of updates coming on BGP which is normally an indicator of network instability being solved by rerouting round the problem. That is all part of the normal operation of the Internet. And sometime yesterday morning as the east coast of the US was getting to work the looming disaster struck.

Juniper network devices started core dumping and restarting due to a bug in the code which handled the BGP UPDATE messages as another large updated was arriving. The self healing properties of the Internet broke and the Internet went with it. The Great Juniper Outage of 2011 was born.

Avoidable?

Almost certainly. The reliance on the hardware of one specific vendor on the part of large ISPs – backbone carriers – creates a single point of failure which is bad – mkay. A fail over situation should always be in place, not just at the ISPs. Companies who rely on the Internet for business should take this into account too. A recent outages at some of companies I consulted said that by placing their faith in one specific vendor they had created a single point of failure which had caused some high profile repercussions.

Recently on NANOG I saw the item below, I was thinking about what this actually means. A computer would – similar to DynDNS – register itself and it’s hostname to a DNS server using some kind of authentication. Naturally I immediately thought this was a brilliant plan, and didn’t understand why nobody, with the exception of DynDNS, had thought of this before. The immediate afterthought was that this would be easy to implement with a soft-token, which is the software equivalent of a physical token like RSA’s SecureID, or complicated to implement with PKI infrastructure.

It will be much better when the OS’s just register themselves in
the DNS. Humans shouldn’t have to do this when a machine renumbers.
Named can already authenticate PTR updates based on using TCP and
the source address of the update. For A/AAAA records you setup a
cryptographically strong authentication first.

DynDNS uses username password, which is less secure than the cryptographically strong solution that Mark Andrews mentions below.