Network Working Group Bernard Aboba INTERNET-DRAFT Microsoft Corporation Glen Zorn 13 June 1996 Microsoft Corporation Dialup Roaming Requirements 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute work- ing documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference mate- rial or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). The distribution of this memo is unlimited. It is filed as , and expires December 14, 1996. Please send comments to the authors. 2. Abstract This document describes the features required for the provision of "roaming capability" for dialup Internet users, as well as offering some suggestions for future protocol standardization work. "Roaming capability" may be loosely defined as the ability to use any one of multiple Internet service providers (ISPs), while maintaining a for- mal, customer-vendor relationship with only one. Examples of cases where roaming capability might be required include ISP "confedera- tions" and ISP-provided coporate network access support. 3. Introduction Considerable interest has arisen recently in a set of features that fit within the general category of "roaming capability" for dialup Internet users. Interested parties have included: Regional Internet Service Providers (ISPs) operating within a particular state or province, looking to combine their efforts with those of other regional providers to offer dialup service Aboba & Zorn [Page 1] INTERNET-DRAFT 13 June 1996 over a wider area. National ISPs wishing to combine their operations with those of one or more ISPs in another nation to offer more comprehensive dialup service in a group of countries or on a continent. Businesses desiring to offer their employees a comprehensive package of dialup services on a global basis. Those services may include Internet access as well as secure access to corporate intranets via a Virtual Private Network (VPN), enabled by tunnel- ing protocols such as PPTP or L2F. What is required to provide roaming capability to dialup users? The following list is a first cut at defining the requirements for suc- cessful roaming among an arbitrary set of ISPs: Phone number presentation Phone number exchange Phone book compilation Phone book update Connection management Authentication NAS Configuration/Authorization Security Accounting These topics are discussed further in following sections. 33..11.. TTeerrmmiinnoollooggyy This document frequently uses the following terms: phone book This is a database or document containing data pertaining to dialup access, including phone numbers and any associated attributes. 4. Requirements for Dialup Roaming Suppose we have a customer, Fred, who has signed up for Internet access with ISP A in his local area, through his company, BIGCO. ISP A has joined an association of other ISPs (which we will call ISP- GROUP) in order to offer service outside the local area. Now Fred travels to another part of the world, and wishes to dial into a phone number offered by ISP B (also a member of ISPGROUP). What is involved in allowing this to occur? Phone number presentation Fred must be able to find and select the phone number offered by ISP B. Aboba & Zorn [Page 2] INTERNET-DRAFT 13 June 1996 Phone number exchange When there is a change in the status of phone numbers (additions or deletions) from individual providers, there must be a way for providers in ISPGROUP to notify each other and propagate the changes. Phone book compilation When these updates occur, there must be a way to compile a new phone book for ISP A, based on the changes submitted by the indi- vidual ISPs in ISPGROUP. Phone book update Once a new phone book is compiled, there must be a way to update the phone books of customers such as Fred, so that the changes are reflected in the user phone books. Connection management Fred's machine must be able to dial the phone number, success- fully connect, and interoperate with the Network Access Server (NAS) on the other end of the line. Authentication Fred must be able to secure access to the network. NAS configuration/authorization The Network Access Server (NAS) must receive configuration param- eters in order to set up Fred's session. Security If desired by BIGCO, additional security measures should be sup- ported for Fred's session. These could include supporting use of token cards, or setting up Fred's account so that he is automati- cally tunneled to the corporate PPTP or L2F server for access to the corporate intranet. Accounting ISP B must keep track of what resources Fred used during the ses- sion. Relevant information might include how long Fred used the service, what speed he connected at, whether he connected via ISDN or modem, etc. Note that some of these requirements may not require standardization or lie outside the scope of the IETF; they are all listed for com- pleteness' sake. 44..11.. PPhhoonnee NNuummbbeerr PPrreesseennttaattiioonn Phone number presentation involves the display of available phone num- bers to the user, and culminates in the choosing of a number. Since the user interface and sequence of events involved in phone number presentation is a function of the connection management software that Fred is using, it is likely that individual vendors will take differ- ent approaches to the problem. These differences may include Aboba & Zorn [Page 3] INTERNET-DRAFT 13 June 1996 variances in the format of the client phone books, varying approaches to presentation, etc. There is no inherent problem with this, as long as the mechanisms by which phone number information is exchanged are standardized and interoperable. The demands of phone number presenta- tion have effects upon the phone book entries themselves, however, as is illustrated below. What information about individual numbers is needed to support the presentation process? We can think of this information as including various qualities associated with a given number (e.g., maximum sup- ported speed, analog vs. ISDN, multicast capability, etc.), as well as additional information specific to a given ISP such as their company name, technical support number or icon. 44..11..11.. PPhhoonnee NNuummbbeerr PPrreesseennttaattiioonn IIssssuueess Issues relating to phone number presentation include: Representation How are the phone numbers represented within the phone book? What information relating to the numbers is presented to the user? Area grouping We assume that, for convenience sake, it would be a good thing to display to Fred only those phone numbers that are useful; the phone numbers of access points in Northern Africa, for instance, are of little use in Los Angeles. If this is true, how can it be accomplished, given that users move around? Number preference What determines what numbers appear first in the list? Primary and secondary numbers Does the user select only a single number to call, or is there a backup number? Representation of external numbers If the geographical coverage areas of two ISPs in the same group overlap, how should they be differentiated, if at all? For exam- ple, suppose that ISP C, another member of ISPGROUP, has some num- bers in the same area as ISP A. Should ISP A be given better "billing" than ISP C in the phone book, since Fred is A's cus- tomer? If so, how should this be accomplished? Cost How are costs to be displayed to users? Is it necessary to propa- gate information on the costs of individual numbers along with the numbers themselves, or would something like a help file suffice? Metrics What information about individual numbers do users want to see? As additional characteristics are added, how do we ensure that this information can also be displayed? Aboba & Zorn [Page 4] INTERNET-DRAFT 13 June 1996 44..22.. PPhhoonnee NNuummbbeerr EExxcchhaannggee Phone number exchange involves propagation of phone number changes between providers. In order for the providers in ISPGROUP to be able to exchange phone book entries with each other, it essential that they be able to interoperate. As a result, we believe there is a need to standardize the phone number exchange protocol. What will the phone number exchange protocol look like between an ISP's phone book server and the Designated Server? The update messages are likely to be fairly simple, consisting of ADD or DELETE messages along with attribute/value pairs. These pairs will describe characteristics of the phone number in question, such as its maximum speed, whether it is ISDN or modem, whether it is multicast capable, etc. 44..22..11.. PPrroottooccooll DDeessiiggnn IIssssuueess Issues involved in the design of the phone number exchange protocol include: Phone book server discovery How do the phone book servers of the roaming partners find each other? While manual configuration will probably work fine as long as ISPGROUP remains small, if ISPGROUP grows large, this could rapidly become unwieldy. Selection of the Designated and Backup Designated Servers Rather than asking each provider in ISPGROUP to contact every other provider, it makes sense to have the providers contact a Designated Server in order to transmit their updates. The Designed Server would then propagate the changes out to the indi- vidual ISP phone book servers, in much the same way as this is handled in OSPF. If the Designated Server became unavailable, a Backup Designated Server would be used; the two servers would need to stay synchronized. Versioning How do different versions of the phone book exchange protocol interoperate? Security How do the interacting phone book servers prove their identities to each other and secure the conversation? Conversation turnaround How do the interacting phone book servers decide who will be the master of the conversation, and how do they then turn the conver- sation around so each side can transmit their updates to the other? Duplicate elimination How are the phone number entries uniquely identified so that duplicate entries are eliminated? It may not be sufficient to automatically kill identical phone numbers, since it is Aboba & Zorn [Page 5] INTERNET-DRAFT 13 June 1996 conceivable that two identical numbers may have different scripts associated with them. Mechanisms for ensuring elimination of duplicates might include generation of a unique phonebook entry ID, and inclusion of a path attribute. Synchronization How often do phone book servers transmit their updates, and how do we guard against excessively frequent updates (phone number flaps)? Failure recovery If a phone number exchange fails part way through, how should recovery be managed? 44..22..22.. PPhhoonnee NNuummbbeerr AAttttrriibbuutteess Since vendors may differ in what information is presented to the user, it is probably a good idea to distinguish between required and optional attributes for each phone number, and provide a mechanism for registering optional (and possibly vendor specific) attributes. That way vendors can extend the protocol (for example, to indicate whether a given number supports multicast). Clients encountering unrecognized optional attributes should ignore them; however, it is important to ensure that the mandatory attribute set is sufficiently rich to sup- port subsequent phone book preparation and phone number presentation. 44..22..22..11.. AAttttrriibbuuttee SSppeecciiffiiccaattiioonn IIssssuueess Issues involved with attribute specification include: Phone number characteristics What information is to be propagated relating to each phone num- ber, in order to assist the user in choosing the "best" one? How do we allow for addition of optional attributes? Scripting Is support for a script attribute required, since some ISPs may require execution of a login script? Origin attribute The origin attribute distinguishes between numbers provided by the "home" ISP (in Fred's case, ISP A) and numbers obtained from external sources, such as other ISPs in the confederation. This would be useful in providing the ability to differentiate between numbers based on source in the client software. Cost attribute Since prices may be expressed in different currencies and rates are likely to change frequently, it is probably undesirable to propagate a cost attribute along with other metrics. Will users find the absence of this information acceptable? Aboba & Zorn [Page 6] INTERNET-DRAFT 13 June 1996 44..33.. PPhhoonnee BBooookk CCoommppiillaattiioonn OOnnccee aann IISSPP''ss pphhoonnee bbooookk sseerrvveerr hhaass rreecceeiivveedd iitt uuppddaatteess ffrroomm tthhee DDeessiiggnnaatteedd SSeerrvveerr iitt nneeeeddss ttoo ccoommppiillee aa nneeww pphhoonnee bbooookk aanndd pprrooppaaggaattee tthhiiss pphhoonnee bbooookk ttoo aallll tthhee pphhoonnee bbooookk sseerrvveerrss ooppeerraatteedd bbyy tthhaatt IISSPP.. IInn tthhee ccaassee ooff IISSPPss wwhhoossee sseerrvviiccee aarreeaass aarree nnoott ggeeooggrraapphhiiccaallllyy oovveerrllaappppeedd,, tthhiiss pprroocceessss ccaann bbee qquuiittee ssiimmppllee.. IInn tthhiiss ccaassee tthhee pphhoonnee bbooookk wwiillll ttyyppiiccaallllyy ccoonnssiisstt ooff aa lliisstt ooff aallll tthhee nnuummbbeerrss oobbttaaiinneedd iinn tthhee uuppddaattee pprroocceessss.. TThheerreeffoorree,, tthhee ccoommppiilleedd pphhoonnee bbooookk wwiillll bbee tthhee ssaammee ffoorr eeaacchh IISSPP iinn tthhee IISSPPGGRROOUUPP aanndd tthhee ssaammee pphhoonnee bbooookk ccaann bbee uusseedd bbyy eevveerryy pphhoonnee bbooookk sseerrvveerr ooppeerraatteedd bbyy tthhee IISSPPss iinn IISSPPGGRROOUUPP.. TThhiiss ggrreeaattllyy ssiimmpplliiffiieess tthhee pprroocceessss,, ssiinnccee iitt iimmpplliieess tthhaatt oonnllyy tthhee DDeessiiggnnaatteedd aanndd BBaacckkuupp DDeessiiggnnaatteedd PPhhoonnee BBooookk SSeerrvveerrss nneeeedd ttoo ddoo tthhee ccoommppiillaattiioonn,, aanndd ccaann tthheenn rreepplliiccaattee tthhee rreessuulltt ttoo aallll ootthheerr sseerrvveerrss iinn IISSPPGGRROOUUPP.. AAss aa rreessuulltt,, aa uusseerr wwoouulldd bbee aabbllee ttoo aacccceessss aannyy ooff tthhee pphhoonnee bbooookk sseerrvveerrss ffrroomm aannyy ooff tthhee IISSPPss iinn IISSPPGGRROOUUPP wwhheenn uuppddaatt-- iinngg tthheeiirr pphhoonnee bbooookk.. 44..33..11.. PPoolliiccyy--bbaasseedd PPhhoonnee BBooookkss If the ISPs overlap in geography, however, things are more compli- cated. In this case, an individual ISP may wish to implement policy- based phonebooks. Examples of phonebook policies include: Excluding all phone numbers from a given ISP Including only those external phone numbers not overlapping in calling area with internal phone numbers Excluding external phone numbers from a given city, state/province, or country Giving preferential listings to internal phone numbers, then to phone numbers from ISP B, then to phone numbers from other exter- nal sources. Implementation of policy-based phone books will require considerable additional work in order to define the possible policy rules and their implementation during the compilation process. Please also note that if the policies of the providers in ISPGROUP differ from one another, then the phone books compiled by the providers will differ. This introduces considerable complexity into the compilation and propaga- tion process. 44..33..22.. SSttaannddaarrddiizzaattiioonn RReeqquuiirreemmeennttss The compilation process probably does not need to be standardized, except as it impacts on the phone number exchange protocol. For exam- ple, there may be a need to specify how tags imported from the phone number exchange process should be stored during compilation, and sub- sequently exported. Aboba & Zorn [Page 7] INTERNET-DRAFT 13 June 1996 44..44.. PPhhoonnee BBooookk UUppddaattee Once the phone book is compiled, it needs to be propagated out to cus- tomers. The phone book update process is considerably simpler than that for phone book exchange. This is because the clients can receive the addresses of their default and backup phone book servers during the process of registering for service; thus there is less of a need for autodiscovery. Also, data transfer is one-way, from the Phone Book server to the client, so a simple version numbering scheme should be adequate to ensure that the client has the latest version. Finally, there is little need to authenticate the client to the server, only for the server to prove its identity to the client. These simplifying attributes allow the Phone Book update process to be handled using existing protocols such as HTTP, with security issues being handled via SSL, PCT or S/HTTP. Since the client machine may in many cases be a very small PC, it is important to keep the update pro- tocol as lightweight as possible. 4.4.1. Standardization Requirements It is probably desirable to standardize some aspects of the phone book update process, so as to allow providers to update user phone books regardless of what client software the customer has installed. The level of standardization desirable is an open question. 4.5. Connection Management Once Fred has chosen a number from his phone book, he will need to connect to ISP B via ISDN or modem, and bring up a dialup network con- nection. In the case of a PPP session, this will include CHAP or PAP authentication. Although it may also be possible (depending on the phone number and ISP chosen) to gain access to the network via SLIP, we feel SLIP is not practical for use in roaming situations since it does not support negotiation of connection parameters and lacks sup- port for protocols other than IP. Support for non-IP protocols (e.g., IPX) may be necessary for the provision of corporate intranet access via the Internet. As a result, we feel that PPP is the only viable dialup protocol for use in roaming situations. 4.5.1. Standardization Requirements All necessary standards activity in this area is being undertaken by the IETF PPP Extensions Working Group. 4.6. Authentication Authentication may be seen as consisting of two parts: the claim of identity (or identification) and the proof of the claim (or verifica- tion). Aboba & Zorn [Page 8] INTERNET-DRAFT 13 June 1996 4.6.1. Identification As part of the authentication process, users identify themselves to the Network Access Server (NAS). This identification may be name- based (as in the classic user ID/password scheme) or it may be based on the telephone number from which the call is made. 4.6.1.1. Name-based Identification If the NAS in question is dedicated to the use of the customers of the ISP which operates it, this identification might be as simple as a flat user ID (e.g., "aboba" or "zorn"). If, however, the NAS is expected to be able to authenticate users from other ISPs (such as the members of ISPGROUP), some means must be provided to correctly route authentication requests to the appropriate authentication server. 4.6.1.1.1. Authentication Request Routing ISPs offering their networks for resale (or shared use, as in the case of ISPGROUP) today frequently implement user IDs including a prefix ("MS/aboba") or suffix "aboba@isbu.microsoft.com") specifying the user's customer affiliation in order to allow authentication to occur against foreign authentication servers or account databases. This method provides simple routing of both authentication requests and accounting data. Note that, although the following discussion uses RADIUS as the authentication protocol, other protocols should work as well. In order for Fred to obtain network access from ISP B, he must have been assigned a user ID which identifies him as a customer of a member of ISPGROUP (in this case, ISP A). If a user ID suffix is used, Fred might identify himself as "fred@ispa.com". Note that some NAS vendors may need to modify their devices so as to support the longer user IDs resulting from addition of prefixes or suffixes. After obtaining Fred's user ID and other authentication data, the NAS device will then forward a RADIUS request packet to a RADIUS proxy. The proxy in turn will examine the user ID suffix, check whether the given suffix represents a authorized authentication domain for roam- ing, and then pass the request on to the appropriate RADIUS server. The mapping between the user's domain and their RADIUS server can be accomplished through either a configuration file on the proxy or DNS resolution. For example, RADIUS requests going to ispa.com might be directed to the server auth.ispa.com. Note that in order to authorize Fred, the RADIUS server receiving the request from the proxy needs to check both the user ID and the domain represented by the suffix. This is to guard against possible misconfiguration of the proxy. Requests coming in with incorrect suffices should probably result in a message sent to the technical representative of the proxy's domain. 4.6.1.2. Telephone Number-based Identification Today there exist ISPs that do not require a network layer authentica- tion, instead handling authorization and accounting based on the Aboba & Zorn [Page 9] INTERNET-DRAFT 13 June 1996 calling phone number. For the case of a user roaming to an ISP that implements telephone-number based billing, if an existing relationship occurs between the phone number owner (say, a hotel) and the ISP, then network access, accounting, and billing can often be simplified. Via the hotel, the user is charged for the resulting 900 number call, and the hotel in turn reimburses the ISP. For the case of a user with a telephone-based billing account roaming to an ISP that requires a net- work layer authentication, the issues are more complex, particularly if the user's software is not set up to handle a network layer authen- tication. At this point, the importance of this issue is an open question. 4.6.2. Verification of Identity CHAP and PAP are the two authentication protocols used within the PPP framework today. Some groups of users are requiring different forms of proof of identity (e.g., token or smart cards, Kerberos creden- tials, etc.) for special purposes (such as acquiring access to corpo- rate intranets). It is outside the scope of this document to describe all the authentication protocols extent, but we believe that the widest possible range of authentication technologies should be sup- ported for roaming to be successful. 44..66..33.. SSttaannddaarrddiizzaattiioonn RReeqquuiirreemmeennttss Other than the shared secrets issue discussed below, the authentica- tion issue is being adequately addressed by the efforts of various IETF Working Groups. 44..77.. NNAASS CCoonnffiigguurraattiioonn//AAuutthhoorriizzaattiioonn In order for Fred to be able to log in to ISP B, it is necessary for ISP A's RADIUS server to return the proper configuration information to ISP B's NAS. However, it is possible that ISP A and ISP B's NAS devices are from different vendors; even if they are from the same vendor, ISP A and ISP B may use different NAS configurations. As a result, the NASs may each require different parameters in order to properly configure them. In the case of RADIUS, this problem can be solved through the use of a proxy which adds ISP- and NAS-specific attributes to the response returned by ISP A's RADIUS server, with the result being that ISP B's RADIUS proxy will provide the attributes necessary to configure ISP B's NAS device, while ISP A's RADIUS server will perform the actual user authentication. 44..77..11.. SSttaannddaarrddiizzaattiioonn RReeqquuiirreemmeennttss Since the NAS configuration function is provided by the RADIUS and TACACS+ protocols, we do not believe there is a need for additional standardization efforts in this area. Aboba & Zorn [Page 10] INTERNET-DRAFT 13 June 1996 44..88.. SSeeccuurriittyy Although network security is a very broad subject, in this paper we will limit our attention to a few topics which seem most relevant to the problem of dialup roaming. These issues include trust, secure tunneling and scalability. 44..88..11.. TTrruusstt One of the problems which arises from the dependency on a proxied sys- tem of authorization is how to guarantee that the proxy will properly forward the security-related parameters returned by the remote server and that the NAS will enforce them. For example, it would probably be unacceptable for the NAS to allow a user to authenticate using only CHAP or PAP if the remote authorization server had returned attributes indicating a requirement for token card use. Unfortunately, we have no idea how (or if it is possible, in the general case) to guarantee this compliance. Probably the best that can be done at this time is to specify that proxies must not remove security-related parameters from responses and require that NAS devices refuse access if they do not support an attribute which is required for a given user. 44..88..22.. SSeeccuurree TTuunnnneelliinngg Several tunneling protocols (notably PPTP and L2F) have been proposed for use in dialup environments. The protocols hold great promise for the implementation of Virtual Private Networks as a means for inexpen- sive access to remote networks. 44..88..22..11.. SSttaannddaarrddiizzaattiioonn RReeqquuiirreemmeennttss Both PPTP and L2F are documented in Internet-Drafts. While we feel that there is a need for standardization in this area, and perhaps for convergence between these two approaches, we do not feel any new tun- neling protocol development is needed for solution of the roaming problem. However, it does appear that there is a need for specifica- tion of how these tunneling protocols will be integrated with advanced authentication methods (such as smart cards) and NAS authentica- tion/authorization protocols, particularly with respect to authentica- tion request routing (see above). 44..88..33.. SSccaallaabbiilliittyy Another issue relating to security is the management of shared secrets. This is probably the issue that most limits scalability of roaming. In order for ISPGROUP to grow beyond a small number of ISPs (say, 5-10) something will have to be done about the existing RADIUS shared secret mechanism. The RADIUS protocol requires a shared secret between the NAS and the RADIUS server. In a proxy implementation, this translates to shared secrets between the NAS devices and the Aboba & Zorn [Page 11] INTERNET-DRAFT 13 June 1996 proxy, and another set of shared secrets between the proxy and the RADIUS servers. In a roaming situation, this means that we could potentially have a shared secret for each proxy/server pair. Assuming that each ISP runs a proxy as well as a server, this translates to n2 shared secrets, where n is the number of ISPs in ISPGROUP. This is in addition to m shared secrets for the NAS/proxy combinations, where m is the total number of NAS devices operated by all the ISPs in ISP- GROUP. Given this, it is fairly easy to see how the shared secret management problem could easily get out of hand. One way to address this issue would be to require assignment of public key pairs to the NAS devices, RADIUS proxies and RADIUS servers. However, this would require implementation of a key distribution mechanism, which is not expected to arrive until the implementation of secure DNS. Also, the use of public-key cryptography is likely to impose an unacceptable computational burden on the NAS. This is really a key management issue, though, rather than a cryptographic one. By simply requiring that all proxies share the same key with any given server, the number of keys in use can be drastically reduced, albeit at the cost of some security. 44..99.. AAccccoouunnttiinngg Given that Fred identifies himself as "fred@ispa.com" in order to login to ISP B, and assuming that ISP B's NAS devices implement an accounting protocol (RADIUS, TACACS+, SNMP, syslog, etc.), an account- ing record will then be generated which will summarize Fred's resource consumption during the session. This record should be provided in a standardized format, and transmitted to an appropriate location. In order to allow the ISPs in ISPGROUP to exchange accounting informa- tion, it is clear that there is a need to standardize the accounting record format, as well as the manner in which these records are trans- mitted among providers. However, as long as the NAS devices only need to communicate with accounting servers within their own organization, it is not as clear that the accounting protocol must itself be stan- dardized. This is because the accounting protocol will only be used as a means of communicating accounting information within an individ- ual ISP's organization. To standardize communication between providers it will suffice to generate accounting records in a defined format and transmit them in a standardized way. Thus, it would not matter what protocol the NAS uses to provide accounting information (i.e. RADIUS accounting, TACACS+, SNMP, syslog, etc.), as long as the required records are generated and transmitted in a secure fashion. 55.. AAcckknnoowwlleeddggeemmeennttss Thanks to Dr. Thomas Pfenning and Don Dumitru of Microsoft for many useful discussions of this problem space. Aboba & Zorn [Page 12] INTERNET-DRAFT 13 June 1996 66.. AAuutthhoorrss'' AAddddrreesssseess Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: 206-936-6605 EMail: bernarda@microsoft.com Glen Zorn Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: 206-703-1559 EMail: glennz@microsoft.com Aboba & Zorn [Page 13]