Corporate View

Appraising And Retraining Your File Services

Over the years, the mainline improvement to remote file services has been the support of multiple zones of control within one trust agency. The sum of the lessons of the AFS, such as multiple naming conventions, trust relationships (which AFS doesn't deal with very well) and lightweight connection-state protocols, have been largely ignored.

Meanwhile, our businesses have reshaped themselves from vertical conglomerates to meshed partnerships. We have no control or operational influence over our business partners' systems, yet we are expected to supply transparent access in this environment of low trust. How can you do your job when your teammates cannot carry their fair share?

The Pressure to Ch ange Typically enough, the pressure to change is coming from the Web's population. The Web comes cl ose to acting as a remote file access service, but it lacks important functions such as solid authentication and access controls, along with efficiencies in file management and update capability. It is highly probable that these and other issues soon will be addressed in Web protocols.

Another not-so-remote possibility is that the Web-like approach to file services could become the model for extensive changes to remote file services. There already are three approaches, at various stages of development, that indicate possible remedial development for our aging remote file systems.

Sun Microsystems, Microsoft and the World Wide Web Consortium (W3C) have Internet drafts that propose how to make a highly scalable remote file system. Sun has taken its venerable Network File System (NFS) and positioned it as a Web protocol. Its proposal, WebNFS Server Specification (ftp://ds.internic.net/internet-drafts/draft-rfced-info-callaghan2-00.txt), defines how NFS can be expanded to use URLs instead of mounts to br ing full file services to the Web. This proposal merges existing technologies for quick remedial action.

Next comes Microsoft. Not to be outdone, Microsoft has brushed off its old proposal for NetBIOS in the Distributed Computing Environment (DCE) with Common Internet File System Protocol (CIFS/1.0), which is described at ftp://ds.internic.net/internet-drafts/draft-heizer-cifs-v1-spec-00.txt. Just as Sun wants to leverage its NFS base, Microsoft plans on doing the same with NetBIOS.

Unlike Sun's proposal, however, Microsoft's CIFS is independent of the Web. That is, the Web can benefit from CIFS, but CIFS does not benefit from the Web. It should be noted that Microsoft, unlike Sun, has yet to propose how browsers might use CIFS instead of Hypertext Transport Protocol (HTTP) to access data. CIFS can be used to maintain Web data, simplifying that process. But the lack of a CIFS interface in browsers will not expand the use of CIFS into the Web.

Finally, the W3C is investigating a number of options for adding needed functionality to HTTP and other parts of the Web. Requirements on HTTP for Distributed Content Editing (ftp://ds.internic.net/internet-drafts/draft-whitehead-http-distreq-00.txt) covers some of the issues that need to be addressed. This document lists 15 general areas for improvement in HTTP to make it an update-capable protocol on top of its retrieval functions.

Although the consortium's is only a requirements document, as opposed to Sun's, which is a description of actual code, we've all seen the speed of enhancements to the Web. There is considerable reason to believe that by the time you read this, many people will be working with beta code that will add access control, locking and updates to HTTP.

Although these three proposals recognize the need for changes in remote file services, their considerable differences are evidence of just how poorly remote file services are meeting our needs.

Microsoft seems quite content with things as they are and intends only some changes t o the undercarriage to allow for much larger growth of NetBIOS. It seems to me that Sun wants us to believe that delivery is the only thing wrong with remote file services. By changing the upper interfaces to NFS, with the addition of the Web for NFS access and using TCP as the transport protocol, Sun supports the accomplishments of its file system and the notion that little else needs to be changed. I guess it's only the Web crowd that is truly dissatisfied with things as they are--just like me.

Whenever I review NetBIOS technical documents, I'm always looking for the kitchen sink, because I know it's in there somewhere. This protocol does everything we've ever done, allowing for easy forward movement with no impetus to ever improve. It is a bad approach over low-bandwidth networks that are unreliable and changeable.

NFS, on the other hand, is too weak in the areas of authentication and access control. This point was underscored in the AFS work, yet little has changed in NFS to remedy this.

The Network Paradigm Has Shifted All this is an interesting and valiant attempt to extend the old ways a little more. But these documents neglect some of the fundamental changes that have occurred in our networks since we started using remote file services. Today's desktops are vastly more capable than yesterday's servers. Yet, we still operate as if this were not the case.

A file server needs to support very little for the workstation. This is particularly true when the workstation is owned and operated by another company. Microsoft's kitchen-sink approach no longer fits the need. A lightweight, secure protocol (with connections going over and through foreign networks) would be more appropriate for the task. Likewise, the need for sound authentication and access control methodologies that readily allow for the clear establishment of trust also are needed; WebNFS does not supply this. But an X.509-based system could. Secure Sockets Layer (SSL) 3.0 or Secure Multipurpose Internet Mail Extensions (S /MIME) files are much better suited to this paradigm.

I've got my remote file system retraining plan worked out for next year. It's time for a major re-education. First, it will have to learn to trust the workstations to take care of themselves and it will have to transfer databases to application servers. What's left will be a prime target for an HTTP-based server. Stay tuned.

Robert Moskowitz is a software systems specialist at Chrysler Corp., Detroit, Mich., and a member of the Internet Architecture Board (IAB). He can be reached at rgm@htt-consult.com.