ROAMOPS Working Group                                    Bernard Aboba
     INTERNET-DRAFT                                               Microsoft
     Category: Standards Track                                    Glen Zorn
     <draft-ietf-roamops-roamreq-05.txt>                          Microsoft
     11 July 1997
                          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   (US  East  Coast),
     (Europe), (US West Coast), or (Pacific Rim).
     The  distribution  of  this memo is unlimited.  It is filed as <draft-
     ietf-roamops-roamreq-05.txt>, and  expires January  1,  1998.   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                                            11 July 1997
          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
          NAS Configuration/Authorization
          Address Assignment/Routing
     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
     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                                            11 July 1997
     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 [4] for defining the signif-
     icance of each particular requirement.  These words are:
     MUST      This  word,  or  the adjectives "REQUIRED" or "SHALL", means
               that the definition is an absolute requirement of the speci-
     MUST NOT  This phrase, or the phrase "SHALL NOT", means that the defi-
               nition is an absolute prohibition of the specification.
     SHOULD    This word, or the adjective "RECOMMENDED", means that  there
               may  exist  valid  reasons  in  particular  circumstances to
               ignore a particular item, but the full implications must  be
               understood and carefully weighed before choosing a different
               This phrase means that there may exist valid reasons in par-
               ticular   circumstances  when  the  particular  behavior  is
               acceptable or even useful, but the full implications  should
               be  understood  and the case carefully weighed before imple-
               menting any behavior described with this label.
     MAY       This word, or the adjective "OPTIONAL", means that  an  item
               is  truly  optional.   One  vendor may choose to include the
               item because a particular marketplace requires it or because
               the  vendor feels that it enhances the product while another
               vendor may omit the same item.  An implementation which does
               not include a particular option MUST be prepared to interop-
               erate with another implementation  which  does  include  the
               option,  though  perhaps  with reduced functionality. In the
               same vein an implementation which does include a  particular
               option  MUST be prepared to interoperate with another imple-
               mentation which does  not  include  the  option.(except,  of
     Aboba & Zorn                                                  [Page 3]

     INTERNET-DRAFT                                            11 July 1997
               course, for the feature the option provides)
     An  implementation is not compliant if it fails to satisfy one or more
     of the must or must not requirements for the protocols it  implements.
     An  implementation  that  satisfies all the must, must not, should and
     should not requirements for its protocols is said to be  "uncondition-
     ally compliant"; one that satisfies all the must and must not require-
     ments but not all the should or should not requirements for its proto-
     cols 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
     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-
     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.
          Fred MUST be able to secure access to the network. If desired  by
          BIGCO,  additional  security  measures  SHOULD  be  supported for
          Fred's session.  This could  include  support  for  smart  cards,
          cryptographic calculators, or one-time passwords.
     Aboba & Zorn                                                  [Page 4]

     INTERNET-DRAFT                                            11 July 1997
     NAS configuration/authorization
          The Network Access Server (NAS) MUST receive configuration param-
          eters in order to set up Fred's session.
          A roaming standard must provide mechanisms for  fraud  prevention
          and detection.
     Address assignment/routing
          Fred  MUST  be assigned a routable IP address by the NAS. Roaming
          MUST also support tunneling using either layer 2 or layer 3  tun-
          neling protocols.
          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.
     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 [1], 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
     Aboba & Zorn                                                  [Page 5]

     INTERNET-DRAFT                                            11 July 1997
     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-
     4.4.1.  Phone book update protocol requirements
     What are the requirements for a phone book update protocol?
          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.
          The client MUST be able to  determine  the  authenticity  of  the
          server  sending  the  phone  book update.  The server MAY also be
          able to authenticate the client.
          The update protocol MUST provide for updating of the  phone  book
          from  an  arbitrary previous version to the latest available ver-
     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 pport
          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.
     Aboba & Zorn                                                  [Page 6]

     INTERNET-DRAFT                                            11 July 1997
     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.
     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.
     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.
          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.
          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.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
     Given the current popularity and near ubiquity of PPP, a roaming stan-
     dard MUST provide support for PPP.  While an implementation MAY choose
     to  support  other  framing  protocols  such  as SLIP, SLIP support is
     Aboba & Zorn                                                  [Page 7]

     INTERNET-DRAFT                                            11 July 1997
     expected to prove difficult since SLIP does not support negotiation of
     connection  parameters  and lacks support for protocols other than IP.
     Support for non-IP protocols (e.g., IPX) MAY be useful for the  provi-
     sion  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 stan-
     4.6.  Authentication
     Authentication consists of two parts: the claim of identity (or  iden-
     tification) and the proof of the claim (or verification).
     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).
     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  authenti-
     cation  request to be routed its home destination.  A roaming standard
     must be provide a standardized format for the userID  and  realm  pre-
     sented  to  the NAS. This userID is also commonly known as the Network
     Access Identifier (NAI).
     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).
     4.6.3.  Requirements
     What are the requirements for authentication?
     Authentication types
          A roaming standard MUST support CHAP,  and  SHOULD  support  EAP.
          Due  to  concerns  over  security  in  chained proxy systems, PAP
          authentication SHOULD NOT be supported.  A possible exception  is
          where PAP is used to support a one time password or token.
     RADIUS Support
          Given the current popularity and near ubiquity of RADIUS, a roam-
          ing standard MUST support RADIUS  authentication  as  defined  in
          [2].   Other  protocols  MAY  be  supported.  However,  it is the
     Aboba & Zorn                                                  [Page 8]

     INTERNET-DRAFT                                            11 July 1997
          responsibility of participating ISPs and/or software  vendors  to
          produce gateways between those protocols and RADIUS.
          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 thousands of ISP members.
     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.
     In order to ensure compatibility with the parameters of the NAS or the
     local  network,  a  RADIUS  proxy  MAY  need to add, delete, or modify
     attributes returned by the home RADIUS server. In addition,  a  RADIUS
     proxy  may need to performance resource management functions. In order
     to ensure interoperability between  RADIUS  proxy  implementations,  a
     roaming  standard  MUST  provide  guidance  on acceptable RADIUS proxy
     4.8.  Address assignment/routing
     A roaming standard MUST support dynamic  address  assignment.   Static
     address  assignment MAY be supported, most likely via layer 2 or layer
     3 tunneling.
     Layer 2 tunneling protocols
          Layer-2 tunneling protocols, such as PPTP,  L2F,  or  L2TP,  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 use of layer 2 tunneling.
          Support of  compulsory  tunneling  via  the  RADIUS  protocol  is
          described in [5] and [6].
     Layer 3 tunneling protocols
          Layer-3  tunneling  protocols as embodied in Mobile IP, described
          in [8], hold great  promise  for  providing  "live",  transparent
          mobility on the part of mobile nodes on the Internet.  Therefore,
          proxy implementations MUST NOT preclude the provision  of  Mobile
          IP Foreign Agents or other Mobile IP functionality on the part of
          service providers.
     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
     Aboba & Zorn                                                  [Page 9]

     INTERNET-DRAFT                                            11 July 1997
     secret management.
     4.9.1.  Requirements
     What are the security requirements?
     Security analysis
          A roaming standard must include  a  thorough  security  analysis,
          including  a description of security threats and countermeasures.
     End-to-end security
          In a RADIUS proxy system, access responses are  verified  hop-by-
          hop,  rather  than  on  an end-to-end basis. As a result, without
          additional security measures, it is impossible to detect  a  man-
          in-the middle attack by a rogue proxy.  While end-to-end security
          is not a requirement of a roaming standard, it MAY be provided as
          an optional capability.
     4.10.  Accounting requirements
     What are the accounting requirements for roaming?
     Real-time accounting
          In  today's  roaming  implementations,  real-time accounting is a
          practical necessity in order to support fraud detection and  risk
          management.  As a result, a roaming standard MUST provide support
          for real-time accounting.
     Accounting record formats
          Today there is no proposed standard for NAS accounting, and there
          is  wide variation in the protocols used by providers to communi-
          cate accounting information within their own organizations. As  a
          result,  a  roaming standard MUST prescribe a standardized format
          for accounting records.
     Accounting Metrics
          A standard accounting record format MUST be able to  encode  met-
          rics commonly used by Internet Service Providers to determine the
          user's bill.
          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.
     Aboba & Zorn                                                 [Page 10]

     INTERNET-DRAFT                                            11 July 1997
          For the sake of efficiency, the record format MUST be compact.
     5.  Acknowledgements
     Thanks  to  Pat Calhoun of USR, Dr. Thomas Pfenning and Don Dumitru of
     Microsoft for many useful discussions of this problem space.
     6.  References
     [1]  B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang.  "Review of  Roaming
     Implementations."  Internet  draft  (work  in  progress),  draft-ietf-
     roamops-imprev-04.txt, Microsoft, Aimnet, i-Pass  Alliance,  Asiainfo,
     Merit, June, 1997.
     [2]   C. Rigney, A. Rubens, W. Simpson, S. Willens.  "Remote Authenti-
     cation Dial In User Service (RADIUS)." RFC  2138,  Livingston,  Merit,
     Daydreamer, April, 1997.
     [3]   C.  Rigney.   "RADIUS  Accounting." RFC 2139, Livingston, April,
     [4] S. Bradner.  "Key words for use in RFCs  to  Indicate  Requirement
     Levels." RFC 2119, Harvard University, March, 1997.
     [5]  G. Zorn.  "RADIUS Attributes for Tunnel Protocol Support." Inter-
     net draft (work  in  progress),  draft-ietf-radius-tunnel-auth-02.txt,
     Microsoft, July, 1997.
     [6]  B.  Aboba.   "Implementation of PPTP/L2TP Mandatory Tunneling via
     RADIUS."  Internet draft (work in progress), draft-ietf-radius-tunnel-
     imp-02.txt, Microsoft, July, 1997.
     [7] C. Rigney, W. Willats.  "RADIUS Extensions."  Internet draft (work
     in progress), draft-ietf-radius-ext-00.txt, Livingston, January, 1997.
     [8] C. Perkins. "IP Mobility Support." RFC 2002, IBM, October, 1996.
     7.  Authors' Addresses
     Bernard Aboba
     Microsoft Corporation
     One Microsoft Way
     Redmond, WA 98052
     Phone: 425-936-6605
     Aboba & Zorn                                                 [Page 11]

     INTERNET-DRAFT                                            11 July 1997
     Glen Zorn
     Microsoft Corporation
     One Microsoft Way
     Redmond, WA 98052
     Phone: 425-703-1559
     Aboba & Zorn                                                 [Page 12]