a slightly bouncy report of a successful IETF meeting
Years ago, it was thought that an IETF meeting in a faraway place like Australia could never be a real meeting.
People would come for a holiday, or not come at all; for sure no work would be done.
Well, I guess we just proved them wrong.
Of 1700+ IETFers who showed up, some did take holiday time - you could recognize those few by their lack of jetlag. But most people showed up, and with the intent to get work done.
And they did.
A very hot topic this time around was the so-called "internationalized DNS".
The idea seems tempting - why don't we "just" start using Æ, Щ, or Chinese ideographs in the DNS, so that it can turn up in email addresses and Web server names "just" like A-Z?
Well - there ain't no such thing as a free lunch.
One hurdle was well recognized by participants: We have to get agreement on how characters are represented on the wire; there are currently 13 or so incompatible experiments trying out various ways, and having registered hundreds of thousands of names between them - in the end there can be only one.
The other hurdle is far more insidious, and far more dangerous: Once we've got those names, how can we use them?
The classic "hostname" concept does not allow even full ASCII to be used (you can't put an @ sign inside a hostname) - and tons of software has been written on the assumption that one will never get back names with a wider character set.
The most alarmist (and perhaps most realistic) version was John Klensin's comment that "global ecommerce will not work in a country that deploys something that breaks the rest of the world." - indicating that a country deploying an internationalized naming scheme without care for the consequences will hurt themselves VERY badly in the Internet marketplace.
It is known for a fact that many implementations, when presented with names in a wider character set where a hostname is expected, do weird things, including, but not limited to, presenting the name in unexpected ways, bouncing messages, corrupting the name in transit, or simply crashing.
There is a requirements document out (draft-ietf-idn-requirements-01.txt) - a -02 document will be expected shortly.
OK, character sets are not the only problem with the DNS.
Another one is security.
In the current DNS, it is a straightforward, if tricky, exercise to make users think that, for instance, "www.citibank.com" is served by the "bandits.inc" webserver, if you have access to the wire between the client and the nameservers - and sometimes even without such access.
(It is of course often much easier to attack the DNS in administative ways, such as by sending in unauthorized update forms to the Internic - but I digress).
We believe that we currently have a set of standards (DNSSEC) that specify security mechanisms that will make it next to impossible to execute such an attack successfully - if the DNS zone in question uses those mechanisms, and the DNS client checks them.
But doubts have remained to this day about whether or not the mechanism could be deployed widely across the Internet.
One problem is that the extra information takes space in the packets; the standard max DNS UDP packet size of 512 bytes is simply too small to fit a good answer - and widespread switching to TCP mode to fetch the "big" answers would kill busy DNS servers.
Apart from that, it seems that most problems are "only" such things as "who signs the root".
Luckily, we've got a solution, called EDNS0, which increases the packet size available to UDP packets.
Unluckily, this is only implemented in BIND 9, which has not been released for general use yet.
It seems most likely that we'll spend a month or three working out these problems; if we're lucky, we may have a signed root by the end of the year.
The next issue is of course to get a signed zone for .com - estimates have been made that signing the full zone will take > 24 hours; not something NSI-as-registry particularly feels good about.
We'll see what happens.
One thing that's quite clear from the state of directories in the IETF is that it's SLOW.
We did the basic work on requirements for LDAP security about 2 years back, in December 1997, and only now is draft-ietf-ldapext-authmeth on its way to becoming an RFC.
The current hot topic in LDAPEXT is access controls - we're beginning to coalesce consensus around the draft "draft-ietf-ldapext-acl-model-05" and corresponding requirements draft, but things take time.
The movements in the industry on XML and friends seem strangely absent from this room. Perhaps not incidentally - those people have learned the hard way that what matters is the data model and semantics; the protocol and syntax are just "surface".
We could reach consensus in a day on how to represent access control - and change it in a week - but if we don't get agreement on what the access controls mean, we will be unable to implement them correctly no matter how clear the protocol is.
Over in LDUP, which started in early 1998, and planned to finish by the end of 1999, there is little sign that the end is in sight. Or maybe there is?
The requirements are there (replica-req-02), the protocol is there (protocol-01), the infomodel may be clear, and people seem generally happy.
Yet there is something missing - the sense of the room isn't that of a group verging on success; rather a group pursuing a worthwhile, but not terribly critical goal.
I suspect that there is a sense of a megatrend passing by here: Directories are more and more seen as enterprise infrastructure, not as global or even public infrastructure.
The chair of the WG is John Strassner, who is also heavily involved with Directory Enabled Networking; he needs to configure devices within an enterprise in situations where single points of failure are unacceptable. He needs a solution.
But most of his customers will buy all their directory servers from a single vendor; why should they care whether it's a standard or not?
There are other advantages of a standard apart from just interworking: You can replace your equipment without changing too much else; you get the guarantee that at least a number of people looked at the solution before implementing it, you get independent documentation on how things are supposed to work. All advantages for buyers and users.
Most people want a standard. But the paranoid among us wonder whether some organizations think that they are better off taking the thinking that got into a standard, build a proprietary product from it, and be able to avoid having to conform exactly to the standard, or even interoperate with other implementations, by saying "it's not published yet".
If the perceived marketplace had been a global directory infrastructure, where it would be impossible to field a non-interoperable product, the stakes would have been different.
But in the current environment, the paranoid may have a point.
After the publication of RFC 2775, "Internet Transparency", there have been two reactions in the community:
The last was the premise of the "FOGLAMPS" BOF, which attempted to look at some means of making new and fancy services work in an increasingly fragile, balkanized and complex Internet.
Guess what? It's hard.
NATs will change your packets; firewalls will block them. Sneaks will be developed; countersneaks will catch'em.
Do you believe you've seen the worst? Then you may not have seen IP over HTTP yet!
(I wish I was joking…..)
Nobody came to any conclusions worth mentioning.
In previous instalments in this series, I've warned of the advent of the telephants: Traditional telephone companies that (sensibly) see a need to operate in the Internet marketplace, but have a hard time finding out exactly what to do once they get there; it takes time to realize that the rules of this game may not be exactly the ones you play by back in Geneva.
The latest twist is of course the mobile revolution, where the telephone companies see that they have extended their reach right to the pockets (and pocketbooks) of millions of users. These users now want more than just voice, and it is the Internet that is going to give it to them.
(For that matter, it is the Internet that will give them voice too - after all, once you've got a multigigabit infrastructure in place for carrying the Internet, who wants to use the old junk for carrying voice around?)
The buzzword of the month is called "WAP", which, according to some, stands for "Worst Application Protocol", but is actually able to deliver some fairly interesting services to a fair number of devices (none of which are widely available just yet, of course). This is mainly an "HTTP replacement" that does its own transport stack, and makes some things easier to do (such as sending over a bunch of tiny webpages at once, rather than having to go round-trip to the server for each part of a transaction).
But it's still very much tied to the "user calls" paradigm; more exciting applications are round the corner when the network can call the user.
But there's a little catch: The number of mobile phones will quickly grow larger than the usable amount of addresses in IPv4. What do we do then?
The WAP answer is to use telco-bound gateways to look at outgoing (WAP) calls, find the right telephone number to dial, and then call it. It's not Internet style.
The long term solution may possibly be IP-to-the-phone, using IPv6, perhaps even with some variation over Mobile-IP for V6 to make mobility even easier.
But the technology - and the telephants - still need to do some work before we get that far.
Other interesting developments include "I-Mode" - a Japanese service that focused on getting content to people, and not standards - user growth is explosive (millions), and standards conformance nearly nonexistent; they did only a small hack to HTML to make content work, rather than replacing it as WAP did.
They also support the WAP initiative.
Of this there was plenty. Most of which went on perfectly fine without me, of course.
There's 6 months left until the RSA patent expires; Crypto Celebration Day is visible on the horizon! - but in the meantime, someone's started taking out patents on ways to defend against some attacks on nonpatented cryptoalgorithms. Pay if you do, hacked if you don't. Grrr.
Can you figure out how you can plop 2 computers, a printer and a router down on a desk, turn them all on, configure nothing, and have everything work securely? If so, the Zeroconf WG would very much like to hear from you.
IPv6 is just around the corner - same place as it's been the last 3 years, but closer to the corner than ever. It's not showing up as growth on the 6bone, however; still only a couple of hundred sites connected.
Oh, well. The future will arrive; we have no other alternative.
The Authentication, Authorization and Accounting stuff is actually getting somewhere after deciding that it does not want to solve all the world's problems - looks as if there will be standards worth using for authenticating yourself to your ISP, or one of his friends, or one of his friends' friends. It's been moving slowly for years - let's hope it's moving this time.
Directory Enabled Networks is still a rathole. Telephony still needs work.
If you don't like TCP, which is a core protocol of the Internet, try SCTP - a protocol developed for signaling transport, but might be useful for some other tricks where TCP's properties aren't exactly what you need.
A few higher level protocol attempts - notably Marshall Rose's "BXXP" and Microsoft's "SOAP" - each were duly noted in their respective BOFs. I'm not betting on them mattering much; we're too good at "not invented here" protocol design. Oh, well.
Oh - and after living with US hotel coffee for too many IETFs, it came as a gratifying surprise that Australians are great at making coffee. Best surprise so far: Double espresso - the slightly surprised waiter when I commented on the fact that it was the same size as a regular: "Oh - did you want more water, too?" Great stuff!
I've forgotten lots of stuff. I may remember more later. Don't bet on it.