Have Clue - Will Travel - Work

Internut Governance

dhankins@mercenary.net (David W. Hankins) — Wed, 05 Nov 2008 17:27:23 -0800

There are a lot of nuts out there. In fact, all of us are more than a little nutty in one way or another.

Recently, I've been thinking a lot more than I should after reading what one more widely spoken nut had to say, in particular;

the human, as a species in the animal kingdom, is known to be the kind of
animal who fouls its own nest and overruns its habitat. the idea of a
tipping point, whether it be for CO2 in the atmosphere or polar ice shelves
or explosively deaggregated IPv4 routing tables, does not occur in the
minds of individual decision makers. instead it's left to us "chicken
little" types, and the only way the individual decision makers ever make
their decisions on the basis of tipping points is if some kind of
"governance" makes them do so.

[1]

Continue reading "Internut Governance"

LISA 2008

dhankins@mercenary.net (David W. Hankins) — Thu, 23 Oct 2008 15:19:46 -0700

Up there in that 'Calendar' section, you'll notice I'm going to LISA 2008. I'm speaking at the W8 tutorial, "DNS and DHCP considerations migrating to IPv6."

What readers want.

dhankins@mercenary.net (David W. Hankins) — Tue, 07 Oct 2008 14:40:30 -0700

So, the single largest webhits I'm getting lately are from the WPAD Howto I wrote earlier.

This is maybe obvious in retrospect; people want information that is useful to them.

I'm thinking of writing more howto's like that, judging by google's ability to send searches here. The question is, what do people want to know?

IVTF Discovery: The Wall wants Spaghetti thrown at it.

dhankins@mercenary.net (David W. Hankins) — Thu, 21 Aug 2008 09:06:47 -0700

Randy Bush wrote a famous rant on the situation between network operators and the network protocol designers (the IETF). In it, he characterized the current situation thus; The Internet Vendors are throwing spaghetti at the wall, just to see what sticks. The criticism is that a lot of protocols overlap in purpose and function, and still more are complete competitors and the IETF can't or won't choose one to standardize...the phrase often used at IETF meetings was "let the market decide." This is essentially a cop-out.

Well, I've made a more recent discovery that will shock you. The wall is asking for spaghetti to be thrown at it.
Continue reading "IVTF Discovery: The Wall wants Spaghetti thrown at it."

WPAD HowTo update.

dhankins@mercenary.net (David W. Hankins) — Wed, 13 Aug 2008 14:50:29 -0700

It ocurred to me that my WPAD HowTo needs to be updated considering the recent Dan Kaminsky DNS vulnerability. This is one more reason to put out a WPAD poison pill, if you're not using it, in your users best interests.

HOWTO: WPAD

dhankins@mercenary.net (David W. Hankins) — Wed, 09 Apr 2008 11:09:30 -0700

WPAD, or Web Proxy AutoDetection, is a protocol that was designed to convey Netscape's PAC format (Proxy Auto Config file) to web browsers automatically - without the user ever having to type a button. It never became an RFC proposed standard, but rather died as an Internet-Draft. I can only wonder what politics led to its demise...but it's full of wonderful hints of terrible flamewars, including the admission that the option code, 252, was 'assigned by the DHC WG chair.' Maybe I need to point out: option codes are never assigned by WG chairs...they are assigned only by IANA after standards action. Meanwhile, 252 is in the "site-local" space - it is not available for allocation! Not by a WG chair, not even by IANA. The site-local options were intended for site administrators (your network's sysadmin) to allocate - not manufacturers.

But its failure to reach RFC did not stop it from becoming the Internet's de facto standard in configuring web proxies. Consequently, whenever your Windows box boots, it tries WPAD to find proxies in order to get Windows Updates...Automatic Updates does this a few minutes after a box reboots. The first thing to do in WPAD is to try DHCP, so you might see Windows boxes try DHCPINFORMs first requesting option 252. They'll try several times until they get 252, and if they never get it, they move on to DNS. They'll query 'wpad.foo.example.com' if foo.example.com were the configured domain name, then 'wpad.example.com', then they give up. They're looking for A records, although the WPAD standard also describes TXT and SRV records (it never tries these). WPAD also describes using SLP after DNS, but I sincerely doubt anyone bothers.

The DNS method is essentially garbage being flooded out on the global Internet. Some older implementations seem to seek right down to 'wpad.'. It seems this is tried in others if no domain name were specified. Your ISP has to deal with wpad.ispname.com being queried all the time, and the rest of the Internet has to cope if the system has some garbled domain name...the query gets passed all the way down to the roots and up.

Edit 2008-08-13: It's also a security problem! Dan Kaminsky has reminded us that it is still, even with all our protections (short of DNSSEC), quite possible to manipulate DNS data. A ne'er do well that creates a cache entry for 'wpad.etc' in front of a horde of WPAD-capable clients can become the man in the middle for all their web content. You can filter for WPAD DNS queries, but it's easier to just make them stop querying for it.

The way to stop all of these clients that implement WPAD from querying DNS at all is to give them a poison pill at DHCP time; or heck configure WPAD at DHCP time and start providing a caching proxy service. I'll show you how to do both below the cut.
Continue reading "HOWTO: WPAD"

Client Classification

dhankins@mercenary.net (David W. Hankins) — Sat, 22 Dec 2007 11:31:27 -0800

Right now, in any published version of ISC DHCP, you can use class {} and subclass statements to make clients a member of one or more classes. These are searched linearly and their 'match' statements are evaluated...although within this linear search of classes, subclasses are looked up on a hash table. The only real way we can improve on this is to identify conditional statements (match statements) that are orthogonal...that cannot both be true. This is hard for a computer to do, considering the conditional statement can be very complex, but is relatively easy for a human writing a config file to sort out. So there's one area we can perhaps improve upon.

You can also create multiple pools of dynamic address ranges within a given shared network (which may or may not span multiple subnets), and then apply an ACL that guides clients of particular classes to particular dynamic pools.

At address allocation time, the worst possible thing happens when we need to put these two sources of information back together again.
Continue reading "Client Classification"

On the Path to Navarone

dhankins@mercenary.net (David W. Hankins) — Thu, 13 Dec 2007 10:27:00 -0800

Fitting the DHCPv6 protocol into ISC DHCP's current software architecture taught me a lot of lessons, and made me start thinking about the software project's architecture and where we can make improvements.

One of the fun and unusual superpowers open source developers get is the ability to describe features in other open source (and sometimes not) projects and steal their ideas without reprisal. We're just allowed to do that, and no one cries foul. This looks a lot like cherry picking from the outside...walking around the garden and choosing the iconic features of software packages that have excelled in their own fields to bring home. It begs mention that things that work well for mail servers do not necessarily work well for DHCP servers. So that's not what it's about.

It just makes it easier to explain where we're going. Like naming the star constellations we're going to steer the ship by.

So to jump to the chase, I think DHCP needs to fork more like Postfix, integrate more like dCop, configure more like OSX, document more like PHP, and run more like dhcpcd (for the client, anyway).

All while keeping those things that make DHCP cooler than the others out there.
Continue reading "On the Path to Navarone"

Definition: IETF

dhankins@mercenary.net (David W. Hankins) — Wed, 05 Dec 2007 16:32:07 -0800

People often try to ask me what it is the IETF does. I'm not really sure I know the answer to that question, since from my point of view the IETF doesn't really accomplish anything on its own. It facilitates others.

But this photo pretty much sums it up. It's from IETF 63, in Paris, where most of us had to bring little adapters to power our equipment on their wacky little power plugs. What you see here is that every slot is in use - this is common enough with enough laptops around. My french->US adapter is powering a 3-slot plug I bring for just this kind of 'sharing'...although usually with my own devices...into which I am plugged, another american is plugged, and a Japanese national has placed his US->japan adapter.

Nothing quite fits and it's a wonder any of it works at all...and it's Turtles All the Way Down.

Internet: Serious Business

dhankins@mercenary.net (David W. Hankins) — Tue, 20 Nov 2007 12:13:07 -0800

Step into the wayback machine, and turn the dial back to April of 1998.

Dave Van Allen of FastNet gifts his son Chris with a domain name, 'pokey.org', for his birthday...matching his family nickname.

The lawyers in charge of the Gumby and Pokey trademarks learned about this.

Hillarity ensues.
Continue reading "Internet: Serious Business"

The Ass and the Frogs (Aesop)

dhankins@mercenary.net (David W. Hankins) — Tue, 07 Aug 2007 08:47:00 -0700

An Ass, carrying a load of wood, passed through a pond. As he was crossing through the water he lost his footing, stumbled and fell, and not being able to rise on account of his load, groaned heavily. Some Frogs frequenting the pool heard his lamentation, and said, "What would you do if you had to live here always as we do, when you make such a fuss about a mere fall into the water?"

Men often bear little grievances with less courage than they do large misfortunes.

I don't think it's necessary to cite some sources if I were to say, "The Internet has some hard problems that need to be solved." Spam is a hard problem, possibly with no real solution. IPv6 has some difficult migration issues. Even in my small corner of the IETF, as I work on DHCP, authenticating DHCP messages is a difficult problem - possibly doubly proven by the presence of an authentication mechanism that few implement, and none use.

I didn't hear any progress on any of those fronts at IETF 69. No one wanted to talk about any of them. We did listen to a presentation which said, basically, "we're running out of IPv4 addresses." I'm not sure why that's news. There was a hubbub over NAT-PT being deprecated. It felt like the whole conference was on cruise control.

What dialogue did we take from IETF 69, back to our homes, to continue to argue to this day?

"At IETF 69, DHCP was sometimes slow."
Continue reading "The Ass and the Frogs (Aesop)"