ROAMOPS Working Group                                    Bernard Aboba
     INTERNET-DRAFT                                   Microsoft Corporation
     <draft-ietf-roamops-roamreq-01.txt>                          Glen Zorn
     30 December 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 <draft-
     ietf-roamops-roamreq-01.txt>, and  expires July 1, 1997.  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" is defined as the ability  to  use  any  one  of  multiple
     Internet  service  providers  (ISPs), while maintaining a formal, cus-
     tomer-vendor relationship with only  one.   Examples  of  cases  where
     roaming  capability might be required include ISP "confederations" and
     ISP-provided corporate 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                                        30 December 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 can
          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, L2F, or L2TP.
     
     What are the elements of a dialup roaming architecture?  The following
     list is a first cut at defining the elements  for  successful  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
          Address Assignment/Routing
          Security
          Accounting
     
     These topics are discussed further in following sections.
     
     
     3.1.  Terminology
     
     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.
     
     phone book server
               This  is  a  server that maintains the latest version of the
               phone book.  Clients communicate with phone book servers  in
               order to keep their phone books up to date.
     
     Network Access Server
               The  Network  Access Server (NAS) is the device that clients
               dial in order to get access to the network.
     
     RADIUS server
               This is a server which  provides  for  authentication/autho-
               rization via the protocol described in [3], and for account-
               ing as described in [4].
     
     
     
     
     
     Aboba & Zorn                                                  [Page 2]


     INTERNET-DRAFT                                        30 December 1996
     
     
     RADIUS proxy
               In order to provide for the routing of RADIUS authentication
               and  accounting requests, a RADIUS proxy can be employed. To
               the NAS, the RADIUS proxy appears to act as a RADIUS server,
               and  to  the  RADIUS  server,  the proxy appears to act as a
               RADIUS client.
     
     Network Access Identifier
               In order to provide for the routing of RADIUS authentication
               and accounting requests, the userID field used in PPP (known
               as the Network Access Identifier or NAI) and in  the  subse-
               quent  RADIUS  authentication  and  accounting requests, can
               contain structure. This structure provides a means by  which
               the  RADIUS  proxy  will locate the RADIUS server that is to
               receive the request.
     
     
     3.2.  Requirements language
     
     This specification uses the same words as RFC 1123  [4]  for  defining
     the significance of each particular requirement.  These words are:
     
     
     MUST      This word or the adjective "required" means that the item is
               an absolute requirement of the specification.
     
     SHOULD    This word or the adjective "recommended"  means  that  there
               MAY  exist  valid  reasons  in  particular  circumstances to
               ignore this item, but the full implications should be under-
               stood  and the case carefully weighed before choosing a dif-
               ferent course.
     
     MAY       This word or the adjective "optional" means that  this  item
               is truly optional. One vendor may choose to include the item
               because a particular marketplace requires it or  because  it
               enhances  the  product, for example; another vendor may omit
               the same item.
     
     An implementation is not compliant if it fails to satisfy one or  more
     of the must requirements for the protocols it implements. An implemen-
     tation that satisfies all the must and all the should requirements for
     its protocols is said to be "unconditionally compliant"; one that sat-
     isfies all the must requirements but not all the  should  requirements
     for its protocols is said to be "conditionally compliant."
     
     
     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
     
     
     
     Aboba & Zorn                                                  [Page 3]


     INTERNET-DRAFT                                        30 December 1996
     
     
     in allowing this to occur?
     
     
     Phone number presentation
          Fred  MUST be able to find and select the phone number offered by
          ISP B.
     
     Phone number exchange
          When there is a change in the status of phone numbers  (additions
          or  deletions)  from  individual providers, providers in ISPGROUP
          will typically notify each other and propagate the changes.
     
     Phone book compilation
          When these updates occur, a new  phone  book  will  be  compiled,
          based  on  the  changes  submitted by the individual ISPs in ISP-
          GROUP.
     
     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,  L2F  or  L2TP  server  for
          access to the corporate intranet.
     
     Address assignment/routing
          Fred MUST be assigned a routable IP address by the NAS.
     
     Accounting
          ISP B MUST keep track of what resources Fred used during the ses-
          sion.  Relevant information includes how long Fred used the  ser-
          vice,  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.
     
     
     
     
     Aboba & Zorn                                                  [Page 4]


     INTERNET-DRAFT                                        30 December 1996
     
     
     4.1.  Phone Number Presentation
     
     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 can include vari-
     ances in the format of the client phone books, varying  approaches  to
     presentation,  etc.   There  is  no  inherent  problem with this. As a
     result, phone number presentation need not be standardized.
     
     
     4.2.  Phone Number Exchange
     
     Phone number exchange involves propagation  of  phone  number  changes
     between  providers  in  a roaming association. As described in [2], no
     current roaming implementations provide for complete automation of the
     phone number exchange process. As a result, phone number exchange need
     not be standardized at this time.
     
     
     4.3.  Phone Book Compilation
     
     Once an ISP's phone book server has received its updates it  needs  to
     compile  a  new  phone  book  and propagate this phone book to all the
     phone book servers operated by that ISP. Given  that  the  compilation
     process  does  not  affect  protocol  interoperability, it need not be
     standardized.
     
     
     4.4.  Phone Book Update
     
     Once the phone book is compiled, it needs to  be  propagated  to  cus-
     tomers.  Standardization  of  the phone book update process allows for
     providers to update the phone books of  users,  independent  of  their
     client and operating system. As a result, roaming implementations pro-
     viding for phone book update MUST implement the standard update proto-
     col.
     
     
     4.4.1.  Phone book update protocol requirements
     
     What are the requirements for a phone book update protocol?
     
     
     Portability
          The update protocol MUST allow for updating of clients on a range
          of platforms and operating systems. Therefore the  update  mecha-
          nism  MUST not impose any operating system-specific requirements.
     
     
     Authentication
          The client MUST be able to  determine  the  authenticity  of  the
     
     
     
     Aboba & Zorn                                                  [Page 5]


     INTERNET-DRAFT                                        30 December 1996
     
     
          server sending the phone book update. The server MAY also be able
          to authenticate the client.
     
     
     Versioning
          The update protocol MUST provide for updating of the  phone  book
          from  an  arbitrary previous version to the latest available ver-
          sion.
     
     
     Integrity Checking
          The client MUST  be  able  to  determine  the  integrity  of  the
          received  update  before applying it, as well as the integrity of
          the newly produced phone book after updating it.
     
     
     Light weight transfers
          Since the client machine can be a low-end PC, the update protocol
          MUST be lightweight.
     
     
     Language support
          The  phone  book  update  mechanism  MUST  support the ability to
          request that the phone book be transmitted in a  particular  lan-
          guage  and character set. For example, if the customer has a Rus-
          sian language software package, then the propagation  and  update
          protocols MUST provide a mechanism for the user to request a Rus-
          sian language phone book. Similarly, the phone book standard
     
     
     4.4.2.  Phone book format requirements
     
     What are the requirements for a phone book format?
     
     
     Phone number attributes
          The phone book format MUST support phone number  attributes  com-
          monly  used  by  Internet service providers. These attributes are
          required in order to provide users with information on the  capa-
          bilities  of  the  available  phone numbers. Since it is intended
          that the client will begin PPP negotiation immediately on connec-
          tion,  support  for scripting will not be part of a roaming stan-
          dard.
     
     
     Provider attributes
          In addition to providing information relating to  a  given  phone
          number, the phone book MUST provide information on the individual
          roaming consortium members.  These  attributes  are  required  in
          order  to  provide  users  with  information about the individual
          providers in the roaming consortium.
     
     
     
     
     
     
     Aboba & Zorn                                                  [Page 6]


     INTERNET-DRAFT                                        30 December 1996
     
     
     Service attributes
          In addition to providing information relating to  a  given  phone
          number,  and service provider, the phone book MUST provide infor-
          mation relevant to configuration of the service. These attributes
          are  necessary to provide the client with information relating to
          the operation of the service.
     
     
     Extensibility
          Since  it  will  frequently  be  necessary  to  add  phone   book
          attributes,  the  phone  book format MUST support the addition of
          phone number, provider and service attributes  without  modifica-
          tion  to  the  update  protocol.  Registration  of new phone book
          attributes will be handled by IANA. The attribute space  MUST  be
          sufficiently large to accomodate growth.
     
     
     Compactness
          Since  phone book will typically be frequently updated, the phone
          book format MUST be compact so as to minimize the bandwidth  used
          in updating it.
     
     
     
     4.4.2.1.  Phone number attributes
     
     Examples of phone number attributes include:
     
          Unique identifier for the phone number
          City
          State or Region
          Country
          Area code
          Local phone number
          Minimum speed
          Maximum speed
          Modem protocols supported (V.32bis, V.34, etc.)
          ISDN protocols supported (V.110, V.120, etc.)
          Multicast capability
          Dialout capability
          Times of operation
          Priority level (for control of presentation order)
          External/internal flag (denoting whether the number has been imported)
     
     
     4.4.2.2.  Provider attributes
     
     Examples of provider attributes include:
     
          Provider name
          Provider address
          Provider voice phone number
          Provider fax phone number
          Customer support phone number
     
     
     
     Aboba & Zorn                                                  [Page 7]


     INTERNET-DRAFT                                        30 December 1996
     
     
          Provider icon
          Provider domain name
          Primary Domain Name Server
          Secondary Domain Name Server
          Dial-up IP Address
          News server
          Mail server
          Web page
          Maximum length of the user name for the provider
          Maximum length of the password for the provider
     
     
     4.4.2.3.  Service attributes
     
     Examples of service attributes include:
     
          The name of the service
          A description of the service
          The URL of the service phone book server
          The service phone book filename
          The service phone book version number
     
     
     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.
     
     
     4.5.1.  Requirements
     
     What are the requirements for connection management?
     
     
      PPP Support
          Given the current popularity and near ubiquity of PPP, a  roaming
          standard  MUST  provide support for PPP.  While an implementation
          MAY choose to support other framing protocols such as SLIP,  SLIP
          support  is  expected to prove difficult since SLIP does not sup-
          port negotiation of connection parameters and lacks  support  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.   Since  it  is intended that the client will
          begin PPP negotiation  immediately  on  connection,  support  for
          scripting will not be part of a roaming standard.
     
     
     4.6.  Authentication
     
     Authentication  consists of two parts: the claim of identity (or iden-
     tification) and the proof of the claim (or verification).
     
     
     
     
     Aboba & Zorn                                                  [Page 8]


     INTERNET-DRAFT                                        30 December 1996
     
     
     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).  For example, if a user  ID  suffix
     is  used,  Fred  might identify himself as "fred@ispa.com".  Note that
     some NAS vendors will 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 send a RADIUS request packet to  a  RADIUS  proxy  or
     server.  If  a proxy is being used, it MUST examine the user ID prefix
     or suffix, check whether it represents  an  authorized  authentication
     realm,   and  then  pass  the  request either to an appropriate RADIUS
     server, or to another proxy for further routing.
     
     
     4.6.1.  Identification
     
     As part of the authentication process, users  identify  themselves  to
     the  Network  Access  Server  (NAS) in a manner that allows the NAS to
     route the authentication request to its home destination.
     
     
     4.6.1.1.  Naming requirements
     
     What are the requirements for an identification scheme?
     
     
      Authentication routing
          A roaming standard MUST provide a mechanism for the remote ISP to
          efficiently  route the authentication request to the home authen-
          tication server. As part of this, there MUST be  a  way  for  the
          remote  ISP  to  determine  the  IP address of the authentication
          server that is to be contacted.
     
     
      Robustness
          Authentication routing MUST be  carried  out  in  a  manner  that
          allows  the  authentication request to reach its the destination,
          and for the response to be returned  to  the  querying  NAS,  all
          within  a time period compatible with typical timeout parameters.
     
     
     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  credentials,
     etc.)  for  special  purposes(such  as  acquiring  access to corporate
     intranets).
     
     
     
     
     
     
     
     
     Aboba & Zorn                                                  [Page 9]


     INTERNET-DRAFT                                        30 December 1996
     
     
     4.6.3.  Requirements
     
     What are the requirements for authentication?
     
     
     Authentication types
          A successful roaming implementation MUST support CHAP, and SHOULD
          support EAP. PAP authentication MAY be supported.
     
     
     RADIUS Support
          Given the current popularity and near ubiquity of RADIUS, a roam-
          ing standard MUST support RADIUS, as  defined  in  [2]  and  [3].
          Other protocols MAY be supported. However, it is the responsibil-
          ity of participating ISPs  and/or  software  vendors  to  produce
          gateways between those protocols and RADIUS.
     
     
     Business relationships
          A roaming standard MUST provide a mechanism for the remote ISP to
          determine whether the home  authentication  server  has  a  valid
          business  relationship  with  the remote ISP. This implies either
          that the authenticating party is a member of the roaming associa-
          tion, or that the authenticating party has a valid business rela-
          tionship with a member of the roaming association.
     
     
     Scalability
          A roaming standard,  once  available,  is  likely  to  be  widely
          deployed  on the Internet. A roaming standard MUST therefore pro-
          vide sufficient scalability to allow for the formation of roaming
          associations  with hundreds of ISP members, and hundreds of "sub-
          domains" per ISP.  Thus, a roaming standard MUST be able to  deal
          with a hundred thousand RADIUS servers operating within a roaming
          association.
     
     
     Non-repudiation
          In a RADIUS proxy system, access responses are  verified  hop-by-
          hop,  rather than on an end-to-end basis. This means that without
          additional security measures, it is possible  for  a  compromised
          RADIUS  proxy  to modify security attributes returned by the home
          ISP, or even to change a NAK to an ACK. While non-repudiation  of
          Access-Replies is not a requirement for a roaming standard, it is
          considered  desirable,  and  therefore  MAY  be  provided  as  an
          optional capability.
     
     
     4.7.  NAS Configuration/Authorization
     
     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.
     
     
     
     
     Aboba & Zorn                                                 [Page 10]


     INTERNET-DRAFT                                        30 December 1996
     
     
     4.7.1.  Configuration/Authorization requirements
     
     What are the requirements for configuration/authorization?
     
     
      Masking of heterogeneity
          ISP A and ISP B's NAS devices can be from different vendors; even
          if they are from the same vendor, ISP A and ISP B can use differ-
          ent  NAS  configurations.  As a result, the NASs can 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 config-
          ure  ISP B's NAS device, while ISP A's RADIUS server will perform
          the actual user authentication.  In order to support  heterogene-
          ity  among providers within the roaming association, RADIUS prox-
          ies MUST support attribute editing.
     
     
     4.8.  Address assignment/routing
     
     A roaming standard MUST support  dynamic  address  assignment.  Static
     address assignment MAY be supported.
     
     Static  address assignment, if it is to be supported, will most likely
     be accomplished via use of tunneling protocols such as PPTP,  L2F,  or
     L2TP.  These  protocols  hold  great promise for the implementation of
     Virtual Private Networks as a means for inexpensive access  to  remote
     networks.  Therefore proxy implementations MUST not preclude mandatory
     tunneling.
     
     
     4.9.  Security
     
     Although network security is a very broad subject, in  this  paper  we
     will limit our attention to the problems of secure proxying and shared
     secret management.
     
     
     4.9.1.  Requirements
     
     What are the security requirements?
     
     
      Secure proxying
          One of the problems which arises from the dependency on a proxied
          system  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. RADIUS proxies
          MUST not remove security-related parameters from  responses.  For
          example,  the user MUST not be allowed to authenticate using CHAP
          or PAP if the remote authorization server had returned attributes
          indicating  a  requirement  for token card use. Similarly, a user
     
     
     
     Aboba & Zorn                                                 [Page 11]


     INTERNET-DRAFT                                        30 December 1996
     
     
          MUST not be allowed access to the Internet if the  remote  autho-
          rization  server had returned attributes indicating a requirement
          for a mandatory tunnel.
     
     
      Shared secret management
          A roaming standard MUST provide for efficient management of share
          secrets.  This  is  required since the RADIUS protocol requires a
          shared secret between the NAS and the RADIUS server.  This  along
          with  authentication  routing  and  timeout  constraints  are the
          issues most limiting the  scalability  of  roaming.  In  a  proxy
          implementation, this translates to shared secrets between the NAS
          devices and the ISP proxy, and  another  set  of  shared  secrets
          between  the  ISP  proxies  and  second  level  proxies or RADIUS
          servers. Note that the issue of shared secret management is inti-
          mately  connected  with authentication routing, since the routing
          scheme determines the number of hops that MUST be  traversed  for
          the authentication request to reach its destination. This in turn
          influences the number of shared secrets that  need  to  be  main-
          tained on each proxy or server.
     
     
     4.10.  Accounting
     
     Today  there  is no proposed standard for NAS accounting, and there is
     wide variation in the  protocols  used  by  providers  to  communicate
     accounting  information  within  their own organizations. As a result,
     rather than requiring  the use of  a  particular  accounting  protocol
     (RADIUS,  TACACS+,  SNMP, SYSLOG, etc.),  a roaming standard MUST pre-
     scribe a standardized format and transmission  method  for  accounting
     records.
     
     
     4.10.1.  Accounting requirements
     
     What are the accounting requirements for roaming?
     
     
     Identification of the accounting agent
          Prior  to  setting up the accounting record transfer, the roaming
          implementation MUST be able to determine  the  endpoint  for  the
          accounting record transfer.
     
     
     Tagging and bagging
          The transfer protocol MUST be able to tag and bag the transferred
          records so as to identify the version and type  of  record  being
          transferred.
     
     
     Accounting metrics
          The account record format MUST be able to encode metrics commonly
          used by Internet Service Providers to determine the user's  bill.
     
     
     
     
     Aboba & Zorn                                                 [Page 12]


     INTERNET-DRAFT                                        30 December 1996
     
     
     Extensibility
          Since  these metrics change over time, the accounting record for-
          mat MUST be extensible so as to be able to add future metrics  as
          they  come  along.  The  record format MUST support both standard
          metrics as well as vendor-specific metrics.
     
     
     Encryption
          For the sake of security, the record transfer protocol MUST  pro-
          vide  for  encrypted transfer of records via an encryption mecha-
          nism that can be legally deployed in at least a  minimal  set  of
          countries.
     
     
     Authentication
          Also  for the sake of security, the record MUST provide for sign-
          ing of the accounting records, so as to  assure  their  integrity
          and  authenticity.  In  addition, during the transfer process the
          sender and receiver MUST mutually authenticate.
     
     
     Compactness
          For the sake of efficiency, the record format MUST be compact.
     
     
     Robustness
          The accounting transfer protocol MUST be  capable  of  recovering
          from a variety of faults, including partially completed transfers
          and non-supported metrics.
     
     
     Non-repudiation
          Once an accounting record file has been transferred,  the  sender
          MUST  be able to secure a receipt from the receiver. Similarly, a
          receipt MUST be sent once the accounting  record  file  has  been
          processed.  Along  with  the receipt, the receiver SHOULD include
          error messages associated with processing the accounting records.
     
     
     4.10.1.1.  Example accounting metrics
     
     Examples of accounting metrics include:
     
          User Name (String; the user's ID, including prefix or suffix)
          NAS IP address (Integer; the IP address of the user's NAS)
          NAS Port (Integer; identifies the physical port on the NAS)
          Service Type (Integer; identifies the service provided to the user)
          NAS Identifier (Integer; unique identifier for the NAS)
          Delay Time (Integer; time client has been trying to send)
          Input Octets (Integer; in stop record, octets received from port)
          Output Octets (Integer; in stop record, octets sent to port)
          Session ID (Integer; unique ID identifying the session)
          Authentication (Integer; indicates how user was authenticated)
          Session Time (Integer; in stop record, seconds of received service)
     
     
     
     Aboba & Zorn                                                 [Page 13]


     INTERNET-DRAFT                                        30 December 1996
     
     
          Input Packets (Integer; in stop record, packets received from port)
          Output Packets (Integer; in stop record, packets sent to port)
          Termination Cause (Integer; in stop record, indicates termination cause)
          Multi-Session ID (String; for linking of multiple related sessions)
          Link Count (Integer; number of links up when record was generated)
          NAS Port Type (Integer; indicates async vs. sync ISDN, V.120, etc.)
     
     
     
     5.  Acknowledgements
     
     Thanks  to  Dr.  Thomas Pfenning and Don Dumitru of Microsoft for many
     useful discussions of this problem space.
     
     
     6.  References
     
     [1]  B. Aboba, L. Liu, J. Alsop, J. Ding.  "Review of  Roaming  Imple-
     mentations."  draft-ietf-roamops-imprev-00.txt,  Microsoft, Aimnet, i-
     Pass Alliance, Asiainfo, November, 1996.
     
     [2]  C. Rigney, A. Rubens, W. A. Simpson, S. Willens.  "Remote Authen-
     tication   Dial   In   User   Service   (RADIUS)."  draft-ietf-radius-
     radius-05.txt, Livingston, Merit, Daydreamer, July 1996.
     
     [3]   C.  Rigney.   "RADIUS  Accounting."   draft-ietf-radius-account-
     ing-05.txt, Livingston, July 1996.
     
     [4]   R.  Braden.   "Requirements for Internet hosts - application and
     support." STD 3, RFC 1123, IETF, October 1989.
     
     [5] G. Zorn.  "RADIUS Attributes for Tunnel Protocol Support."  draft-
     zorn-radius-tunnel-auth-00.txt, Microsoft Corporation, November, 1996.
     
     [6] B. Aboba.  "Implementation of  Mandatory  Tunneling  via  RADIUS."
     draft-aboba-radius-tunnel-imp-01.txt, Microsoft Corporation, November,
     1996.
     
     
     7.  Authors' Addresses
     
     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
     
     
     
     Aboba & Zorn                                                 [Page 14]


     INTERNET-DRAFT                                        30 December 1996
     
     
     Phone: 206-703-1559
     EMail: glennz@microsoft.com
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Aboba & Zorn                                                 [Page 15]