A Practical Navigator for the Internet Economy


Protocol Debuts as Part of Public Key Exchange and Authentication System Not Vulnerable to Key Escrow pp. 1 - 6

We interview Bob Moskowitz, one of the creators of IP sec, which is a complete security system for Internet traffic. A protocol for protecting information in transit, IP sec includes data framing, encryption and authentication algorithms. The IP sec data frame is a new header that is being slipped in between the IP and higher level protocols.

The IP sec protocol supports many different encryption algorithms such as DES, triple DES, CAST and others. Using symmetric encryption, it has a key management protocol known as Oakley/ISAKMP. By using Oakley, the two parties' hosts can exchange necessary information to generate the keys used by IP sec. They can - safely and securely - without any parties in between understanding - generate and exchange key material. Oakley supplies something called Perfect Forward Secrecy (PFS). The two sides can do this in such a manner that if a third party were to listen to and record the session, and obtain the private keys used to initiate the session, that third party would still be unable to open up the session.

Oakley offers a quick mode and a main mode for creating new session keys during the session. This makes capturing your key a moving target. Oakley further strengthens IP sec (which is a tightly architected set of envelopes difficult to attack) by doing the key exchange in a non attackable way. In other words, if users choose, Oakley's ability to generate keys on the fly makes key escrow irrelevant. Oakley also adds the capability for the exchange of digital signatures to IP sec. This enables users to be sure that they are talking only to an intended host.

By tunneling, IP sec enables Virtual Private Networking to be used securely on the public Internet. Consequently, any road warrior with a laptop may initiate an IP sec dial-up session with an IP sec capable corporate firewall. This will also make it possible to use the public Internet rather than leased lines for communication with branch offices.

IP sec, over the next two years, will also be implemented at the application level where users can individually tailor what kind of secure communications they wish for those with whom they communicate. In final beta now, IP sec has been mandated by the Automotive Industry Action Group for communication with its parts suppliers. Commercial release is expected by November.


A Look at Technical Issues Involved in Moving "dot" pp. 7 - 12, 19

We offer some analyses from early August and a fresh update as of the 22nd of the month. Word from the just concluded Munich IETF is that the hoped for institutionalization of the IANA functions by the registries is becoming less and less likely.

Jon Postel has now stated his desire to move the "dot" to ISI. On August 11 the NSF, at the request of the U.S. Government, ordered NSI not to add any new TLDs to the root servers. Since the feds are interferring to this degree, we conclude that they would be likely to tell NSI not to cooperate with Postel in such a move. We describe the technology issues involved in moving the "dot" files and initially concluded that NSI wouldn't dare to do anything except cooperate. Without NSI's cooperation the move could not be completed and Postel would have to appeal over NSI's head to the operators of the DNS servers to change their root.cache files.

We now believe that the feds are ready to tell NSF to forbid NSI to cooperate in the movement of the "dot". This would likely create a stalemate, unless John were determined to risk everything on a public appeal. In the meantime, as the NOI plays itself out, and it becomes evident that the U.S. government may forbid new top level domains, the IAHC/IPOC process has slowed to a crawl. By now they were to have had all the applications for new gTLD registrars. While twenty-eight were to have been selected, it looks as though they have received four applicants - three of which are acceptable.

While ARIN began accepting membership applications on August 10, we find it most unfortunate that the IANA-based policy processes needed to bullet proof the IP allocation process have not, as far as we can tell, begun. Jon Postel continues to serenely carry on choosing not to recognize the turmoil around him.


A "Guide" to the Impact of 96 Telecom Act on ISPs Common Carrier Status - Costs and Benefits, pp. 13 - 19

We interview W. Scott McCollough, a telecom attorney who was a data com geek before he became a lawyer and started advising Texas ISPs on how to cope with the phone company. Scott emphasizes two things that ISP's may do in the new telecom environment to increase their prospects of long health.

First those, with at least $100,000 to invest beyond the state of their current set up, may examine the issue of becoming a common carrier. He points out that the 1996 Telecom Act does not give the ISP a right to interconnect or get unbundled network elements in the same fashion that MCI, AT&T, Sprint or Teleport can, unless the ISP first becomes certified as a common carrier. This is why he is running many of his medium sized to larger ISP clients through the certification process and then, once that is complete, actually working with them to conduct telco interconnection negotiations. Such negotiations he notes can be as cumbersome as the certification process itself.

Finally, he explains how ISPs can protect themselves by learning how to read the tariffs of the incumbent local exchange carrier. Most of the complaints that he hears about telco pricing are directly answered by explicit language in the tariff, and most of the time they are resolvable in the ISP's favor. If the ISP can go to the correct language within the tariff, it will solve everyone's problem. The tariff does give the ISP substantive rights to enforce against the telco, if the ISP just knows where to look.


Jeff Sedayao Talks about Intel's Experience , pp. 20 -22, 24

We interview Jeff Sedayao who, with Cindy Bickerstaff, developed a methodology of using software called Timeit to measure responses from a provider pop near Intel to hundreds of web sites of interest to Intel employees. Jeff explains to us what Intel did. It would take measurements from the pops of several NSPs nearest to the point at which it wanted services and in comparing the results could make useful conclusions about the relative quality of service that it might get from those NSPs at that particular location.

Boardwatch did its own "test" of 29 backbones in May of this year. But it did it in such a way as to attract heavy criticism of its methodology from some of the most knowledgable engineers in the Internet. Working in conjunction with a company known as Keynote, it used 27 cities in which Keynote had test platforms to querry the home page of 29 different backbone providers. Boardwatch presented the results as measuring the comparative performance of the 29 backbones. The critics claimed, correctly we believe, that the test measured nothing more but average times between a backbone web server and the Keynote polling machines. They claimed that among the variables that would not be uniform from backbone to backbone would be the placement of the server, its speed, the speed of DNS response and, in the case of some polling machines on multiply homed networks, even the routes to the web servers over time.

We include, with permission in every case, reponses to the Boardwatch tests. The first response is from MCI. It lists the shortcomings and offers suggestions for improvements. The second is from the Director of Network Architecture from BBN and critiques the methodology. The third is from Intel's Jeff Sedayao and decsribes the similarities in the Intel and Boardwatch tests but then concludes with a discussion of how the tests differ in three very important areas. We believe that obtaining a sound outcome to this debate is very critical to the development of meaningful standards for the measurement of IP network performance.