<pre>Network Working Group                                          B. Aboba
Request for Comments: 2477                                      G. Zorn
Category: Informational                           Microsoft Corporation
                                                           January 1999


               <span class="h1">Criteria for Evaluating Roaming Protocols</span>

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Abstract</span>

   This document describes requirements for the provisioning of "roaming
   capability" for dialup Internet users.  "Roaming capability" is
   defined as the ability to use multiple Internet service providers
   (ISPs), while maintaining a formal, customer-vendor relationship with
   only one.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Introduction</span>

   Operational roaming services are currently providing worldwide
   roaming capabilities, and these services continue to grow in
   popularity [<a href="#ref-1" title="&quot;Review of Roaming Implementations&quot;">1</a>].  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 services over a
      wider area.

      National ISPs wishing to combine their operations with those of
      one or more ISPs in another nation to provide greater coverage 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).






<span class="grey">Aboba &amp; Zorn                 Informational                      [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc2477">RFC 2477</a>              Evaluating Roaming Protocols          January 1999</span>


   This document provides an architectural framework for the
   provisioning of roaming capabilities, as well as describing the
   requirements that must be met by elements of the architecture.

<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>.  Requirements language</span>

   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
   "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
   described in [<a href="#ref-4" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">4</a>].

   Please note that the requirements specified in this document are to
   be used in evaluating protocol submissions.  As such, the
   requirements language refers to capabilities of these protocols; the
   protocol documents will specify whether these features are required,
   recommended, or optional for use in roaming.  For example, requiring
   that a protocol support confidentiality is NOT the same thing as
   requiring that all protocol traffic be encrypted.

   A protocol submission is not compliant if it fails to satisfy one or
   more of the must or must not requirements for the capabilities that
   it implements.  A protocol submission that satisfies all the must,
   must not, should and should not requirements for its capabilities is
   said to be "unconditionally compliant"; one that satisfies all the
   must and must not requirements but not all the should or should not
   requirements for its protocols is said to be "conditionally
   compliant."

<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>.  Terminology</span>

   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.

   Authentication server
      This is a server which provides for authentication/authorization
      within the roaming architecture.



<span class="grey">Aboba &amp; Zorn                 Informational                      [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc2477">RFC 2477</a>              Evaluating Roaming Protocols          January 1999</span>


   Accounting server
      This is a server which provides for accounting within the roaming
      architecture.

   Authentication proxy
      Authentication proxies may be deployed within the roaming
      architecture for several purposes, including authentication
      forwarding, policy implementation, shared secret management, and
      attribute editing.  To the NAS, the authentication proxy appears
      to act as an authentication server; to the authentication server,
      the proxy appears to act as an authentication client.

   Accounting proxy
      Accounting proxies may be deployed within the roaming architecture
      for several purposes, including accounting forwarding, reliability
      improvement, auditing, and "pseudo-transactional" capability.  To
      the NAS, the accounting proxy appears to act as an accounting
      server; to the accounting server, the proxy appears to act as an
      accounting client.

   Network Access Identifier
      In order to provide for the routing of authentication and
      accounting packets, user name MAY contain structure.  This
      structure provides a means by which the authentication or
      accounting proxies will locate the authentication or accounting
      server that is to receive the request.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Architectural framework</span>

   The roaming architecture consists of three major subsystems:

      Phone book Subsystem
      Authentication Subsystem
      Accounting Subsystem

   The phone book subsystem is concerned with the maintenance and
   updating of the user phone book.  The phone book provides the user
   with information on the location and phone numbers of Points of
   Presence (POPs) that are roaming enabled.  The function of the
   authentication subsystem is to provide authorized users with access
   to the POPs in the phonebook, and to deny access to unauthorized
   users.  The goal of the accounting subsystem is to provide
   information on the resources utilized during the user's session.

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Phone Book Subsystem</span>

   The phone book subsystem provides for the following:




<span class="grey">Aboba &amp; Zorn                 Informational                      [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc2477">RFC 2477</a>              Evaluating Roaming Protocols          January 1999</span>


      Phone number presentation
      Phone number exchange
      Phone book compilation
      Phone book update

   Phone number presentation
      Phone number presentation involves the display of available phone
      numbers 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 being used, it is likely that individual vendors will
      take different approaches to the problem.  These differences can
      include variances 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.

   Phone number exchange
      Phone number exchange involves propagation of phone number changes
      between providers in a roaming association.  Current roaming
      implementations do not provide for complete automation of the
      phone number exchange process [<a href="#ref-1" title="&quot;Review of Roaming Implementations&quot;">1</a>].  As a result, phone number
      exchange need not be standardized at this time.

   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.

   Phone book update
      Once the phone book is compiled, it needs to be propagated to
      users.  Standardization of the phone book update process allows
      for providers to update user phone books, independent of their
      client software or operating system.

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Authentication Subsystem</span>

   The authentication subsystem provides for the following:

      Connection management
      Authentication
      NAS Configuration/Authorization
      Address Assignment/Routing
      Security





<span class="grey">Aboba &amp; Zorn                 Informational                      [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc2477">RFC 2477</a>              Evaluating Roaming Protocols          January 1999</span>


   Connection management
      In order to be able to use the POPs of the local provider, it is
      first necessary to bring up a connection.

   Identification
      Authentication consists of two parts: the claim of identity (or
      identification) and the proof of the claim (or verification).  As
      part of the authentication process, users identify themselves to
      the Network Access Server (NAS) in a manner that allows the
      authentication request to be routed its home destination.

   Authentication
      Authentication is typically required prior to allowing access to
      the network.  CHAP [<a href="#ref-8" title="&quot;PPP Challenge Handshake Authentication Protocol (CHAP)&quot;">8</a>] and PAP [<a href="#ref-9" title="&quot;PPP Authentication Protocols&quot;">9</a>] are the two authentication
      protocols most commonly used within the PPP [<a href="#ref-10" title="&quot;The Point-to-Point Protocol (PPP)&quot;">10</a>] 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).  The Extensible Authentication Protocol (EAP) [<a href="#ref-7" title="&quot;PPP Extensible Authentication Protocol (EAP)&quot;">7</a>] was
      created in order to provide a general mechanism for support of
      these methods.

   NAS configuration/authorization
      In order to set up the session, authorization parameters need to
      be sent to from the home authentication server to the local ISP's
      NAS.

   Address assignment/routing
      If it is desired that the user be able to communicate with the
      rest of the Internet, then the session will be assigned a routable
      IP address by the NAS.

   Security
      In the process of authenticating and authorizing the user session,
      it may be desirable to provide protection against a variety of
      security threats.

<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>.  Accounting Subsystem</span>

   The function of the accounting subsystem is to enable the
   participants in the roaming consortium to keep track of what
   resources are used during a session. Relevant information includes
   how long the user was connected to the service, connection speed,
   port type, etc.







<span class="grey">Aboba &amp; Zorn                 Informational                      [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc2477">RFC 2477</a>              Evaluating Roaming Protocols          January 1999</span>


<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Roaming Requirements</span>

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  Phonebook requirements</span>

<span class="h4"><a class="selflink" id="section-4.1.1" href="#section-4.1.1">4.1.1</a>.  Phone book update protocol</span>

   Portability
   The update protocol MUST allow for updating of clients on a range of
   platforms and operating systems. Therefore the update mechanism MUST
   NOT impose any operating system-specific requirements.

   Authentication
   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.

   Versioning
   The update protocol MUST provide for updating of the phone book from
   an arbitrary previous version to the latest available version.

   Integrity Checking
   The client MUST be able to determine the integrity of the received
   update before applying it, and MUST be able to determine the
   integrity of the newly produced phone book after updating it.

   Light weight transfers
   Since the client may be a low-end machine or internet appliance, 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 language and
   character set.  For example, if the customer has a Russian language
   software package, then the propagation and update protocols MUST
   provide a mechanism for the user to request a Russian language phone
   book.

<span class="h4"><a class="selflink" id="section-4.1.2" href="#section-4.1.2">4.1.2</a>.  Phone book format</span>

   Phone number attributes
   The phone book format MUST support phone number attributes commonly
   used by Internet service providers.  These attributes are required in
   order to provide users with information on the capabilities 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



<span class="grey">Aboba &amp; Zorn                 Informational                      [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc2477">RFC 2477</a>              Evaluating Roaming Protocols          January 1999</span>


   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 information
   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 modification 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.

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  Authentication requirements</span>

<span class="h4"><a class="selflink" id="section-4.2.1" href="#section-4.2.1">4.2.1</a>.  Connection Management</span>

   Given the current popularity and near ubiquity of PPP, a roaming
   standard MUST provide support for PPP and IP. A roaming standard MAY
   provide support for other framing protocols such as SLIP.  However,
   SLIP support is expected to prove difficult since SLIP does not
   support negotiation of connection parameters and lacks support for
   protocols other than IP.

   A roaming standard MAY provide support for non-IP protocols (e.g.,
   IPX or AppleTalk) since these may be useful 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 SHOULD NOT be part of a roaming standard.

<span class="h4"><a class="selflink" id="section-4.2.2" href="#section-4.2.2">4.2.2</a>.  Identification</span>

   A roaming standard MUST provide a standardized format for the userID
   and realm presented to the NAS.






<span class="grey">Aboba &amp; Zorn                 Informational                      [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc2477">RFC 2477</a>              Evaluating Roaming Protocols          January 1999</span>


<span class="h4"><a class="selflink" id="section-4.2.3" href="#section-4.2.3">4.2.3</a>.  Verification of Identity</span>

   Authentication types
      A roaming standard MUST support CHAP, and SHOULD support EAP.  Due
      to security concerns, PAP authentication SHOULD NOT be supported.
      A possible exception is where PAP is used to support a one time
      password or token.

   Scalability
      A roaming standard, once available, is likely to be widely
      deployed on the Internet.  A roaming standard MUST therefore
      provide sufficient scalability to allow for the formation of
      roaming associations with thousands of ISP members.

   RADIUS Support
      Given the current popularity and near ubiquity of RADIUS [<a href="#ref-2" title="&quot;Remote Authentication Dial In User Service (RADIUS)&quot;">2</a>,<a href="#ref-3" title="&quot;RADIUS Accounting&quot;">3</a>] as
      an authentication, authorization and accounting solution, a
      roaming standard MUST be able to incorporate RADIUS-enabled
      devices within the roaming architecture. It is expected that this
      will be accomplished by development of gateways between RADIUS and
      the roaming standard authentication, authorization, and accounting
      protocol.

<span class="h4"><a class="selflink" id="section-4.2.4" href="#section-4.2.4">4.2.4</a>.  NAS Configuration/Authorization</span>

   In order to ensure compatibility with the NAS or the local network,
   authentication/authorization proxies often will add, delete, or
   modify attributes returned by the home authentication server. In
   addition, an authentication proxy will often carry out resource
   management and policy functions.  As a result, a roaming standard
   MUST support the ability of proxies to perform attribute editing and
   implement policy.

<span class="h4"><a class="selflink" id="section-4.2.5" href="#section-4.2.5">4.2.5</a>.  Address assignment/routing</span>

   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.

   Layer 3 tunneling protocols
      Layer-3 tunneling protocols as embodied in Mobile IP [<a href="#ref-5" title="&quot;IP Mobility Support&quot;">5</a>], hold
      great promise for providing "live", transparent mobility on the



<span class="grey">Aboba &amp; Zorn                 Informational                      [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc2477">RFC 2477</a>              Evaluating Roaming Protocols          January 1999</span>


      part of mobile nodes on the Internet.  Therefore, a roaming
      standard MUST NOT preclude the provisioning of Mobile IP Foreign
      Agents or other Mobile IP functionality on the part of service
      providers.

<span class="h4"><a class="selflink" id="section-4.2.6" href="#section-4.2.6">4.2.6</a>.  Security</span>

   Security analysis
      A roaming standard MUST include a thorough security analysis,
      including a description of security threats and countermeasures.
      This includes specification of mechanisms for fraud prevention and
      detection.

   Hop by hop security
      A roaming standard MUST provide for hop-by-hop integrity
      protection and confidentiality.  This MAY be accomplished through
      support of network layer security (IPSEC) [<a href="#ref-6" title="&quot;Security Architecture for the Internet Protocol&quot;">6</a>].

   End-to-end security
      As policy implementation and attribute editing are common in
      roaming systems, proxies may need to modify packets in transit
      between a local NAS and the home server. In order to permit
      authorized modifications while at the same time guarding against
      attacks by rogue proxies, it is necessary for a roaming standard
      to support data object security.  As a result, a roaming standard
      MUST provide end-to-end confidentiality and integrity protection
      on an attribute-by-attribute basis.  However, non-repudiation is
      NOT a requirement for a roaming standard.

<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>.  Accounting requirements</span>

   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
      communicate accounting information within their own organizations.
      Therefore, a roaming standard MUST prescribe a standardized format
      for accounting records.  For the sake of efficiency, the record
      format MUST be compact.

   Extensibility
      A standard accounting record format MUST be able to encode metrics
      commonly used to determine the user's bill.  Since these metrics



<span class="grey">Aboba &amp; Zorn                 Informational                      [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc2477">RFC 2477</a>              Evaluating Roaming Protocols          January 1999</span>


      change over time, the accounting record format 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.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  References</span>

   [<a id="ref-1">1</a>] Aboba, B., Lu, J., Alsop, J., Ding, J. and W. Wang, "Review of
       Roaming Implementations", <a href="./rfc2194">RFC 2194</a>, September 1997.

   [<a id="ref-2">2</a>] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
       Authentication Dial In User Service (RADIUS)", <a href="./rfc2138">RFC 2138</a>, April
       1997.

   [<a id="ref-3">3</a>] Rigney, C., "RADIUS Accounting", <a href="./rfc2139">RFC 2139</a>, April 1997.

   [<a id="ref-4">4</a>] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

   [<a id="ref-5">5</a>] Perkins, C., "IP Mobility Support", <a href="./rfc2002">RFC 2002</a>, October 1996.

   [<a id="ref-6">6</a>] Kent, S. and R. Atkinson, "Security Architecture for the Internet
       Protocol", <a href="./rfc2401">RFC 2401</a>, November 1998.

   [<a id="ref-7">7</a>] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
       Protocol (EAP)", <a href="./rfc2284">RFC 2284</a>, March 1998.

   [<a id="ref-8">8</a>] Simpson, W., "PPP Challenge Handshake Authentication Protocol
       (CHAP)", <a href="./rfc1994">RFC 1994</a>, August 1996.

   [<a id="ref-9">9</a>] Lloyd, B. and Simpson, W., "PPP Authentication Protocols", <a href="./rfc1334">RFC</a>
       <a href="./rfc1334">1334</a>, October 1992.

   [<a id="ref-10">10</a>] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, <a href="./rfc1661">RFC</a>
        <a href="./rfc1661">1661</a>, July 1994.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Security Considerations</span>

   This document, being a requirements document, does not have any
   security concerns.  The security requirements on protocols to be
   evaluated using this document are mainly described in <a href="#section-5.2">section 5.2</a>.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Acknowledgements</span>

   Thanks to Pat Calhoun (pcalhoun@eng.sun.com), Butch Anton
   (butch@ipass.com) and John Vollbrecht (jrv@merit.edu) for many useful
   discussions of this problem space.




<span class="grey">Aboba &amp; Zorn                 Informational                     [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc2477">RFC 2477</a>              Evaluating Roaming Protocols          January 1999</span>


<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Authors' Addresses</span>

   Bernard Aboba
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052

   Phone: 425-936-6605
   EMail: bernarda@microsoft.com


   Glen Zorn
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052

   Phone: 425-703-1559
   EMail: glennz@microsoft.com

































<span class="grey">Aboba &amp; Zorn                 Informational                     [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc2477">RFC 2477</a>              Evaluating Roaming Protocols          January 1999</span>


<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  Full Copyright Statement</span>

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Aboba &amp; Zorn                 Informational                     [Page 12]
</pre>