[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 rfc2477                      
ROAMOPS Working Group                                      Bernard Aboba
INTERNET-DRAFT                                                 Glen Zorn
Category: Standards Track                          Microsoft Corporation
<draft-ietf-roamops-roamreq-09.txt>                           April 1998


                          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 working doc-
uments 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  material
or to cite them other than as ``work in progress.''

To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).

The distribution of this memo is unlimited.  It is filed as <draft-ietf-
roamops-roamreq-09.txt>, and expires October 10, 1998.  Please send com-
ments  to  the   Roaming   Operations   Working   Group   mailing   list
(roamops@tdmx.rutgers.edu),  or  to  the authors (bernarda@microsoft.com
and glennz@microsoft.com).


2.  Abstract

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.


3.  Introduction

As  described in [1], operational roaming services are currently provid-
ing worldwide roaming capabilities, and these services continue to  grow
in popularity.  Interested parties have included:

     Regional  Internet  Service  Providers  (ISPs)  operating  within a



Aboba & Zorn                                                    [Page 1]


INTERNET-DRAFT            Roaming Requirements                April 1998


     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  pack-
     age  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).

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.


3.1.  Requirements language

This  document specifies a set of requirements for elements of the roam-
ing architecture, and uses the same words as [4] for defining  the  sig-
nificance 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  specifica-
          tion.

MUST NOT  This phrase, or the phrase "SHALL NOT", means that the defini-
          tion 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  under-
          stood  and  carefully  weighed  before  choosing  a  different
          course.

SHOULD NOT
          This phrase means that there may exist valid reasons  in  par-
          ticular  circumstances when the particular behavior is accept-
          able or even useful,  but  the  full  implications  should  be
          understood  and the case carefully weighed before implementing
          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



Aboba & Zorn                                                    [Page 2]


INTERNET-DRAFT            Roaming Requirements                April 1998


          may omit the same item.   An  implementation  which  does  not
          include  a  particular option MUST be prepared to interoperate
          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 implementation which
          does not include the option (except, of course, for  the  fea-
          ture the option provides).

Please  note  that the requirements specified in this document are to be
used in evaluating protocol submissions.  As such, the requirements lan-
guage  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 sup-
port confidentiality is NOT the same thing as requiring that all  proto-
col traffic be encrypted.

An  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."


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

Authentication server
          This is a server which provides for  authentication/authoriza-
          tion within the roaming architecture.




Aboba & Zorn                                                    [Page 3]


INTERNET-DRAFT            Roaming Requirements                April 1998


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, and to the authen-
          tication server, the proxy appears to act as an authentication
          client.

Accounting proxy
          Accounting proxies may be deployed within the  roaming  archi-
          tecture 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, and 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, the userID field used in PPP (known as the
          Network  Access Identifier or NAI) may contain structure. This
          structure provides a means  by  which  the  authentication  or
          accounting  proxies will locate the authentication or account-
          ing server that is to receive the request.


4.  Architectural framework

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 informa-
tion 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 subsys-
tem is to provide information  on  the  resources  utilized  during  the
user's session.





Aboba & Zorn                                                    [Page 4]


INTERNET-DRAFT            Roaming Requirements                April 1998


4.1.  Phone Book Subsystem

The phone book subsystem provides for the following:

     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  that  Fred is using, 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. 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.

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  compi-
     lation  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  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.


4.2.  Authentication Subsystem

The authentication subsystem provides for the following:

     Connection management
     Authentication



Aboba & Zorn                                                    [Page 5]


INTERNET-DRAFT            Roaming Requirements                April 1998


     NAS Configuration/Authorization
     Address Assignment/Routing
     Security

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 authen-
     tication request to be routed to its home destination.

Authentication
     Authentication is typically required prior to  allowing  access  to
     the  network.   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).   The  Extensible
     Authentication Protocol (EAP) 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 MUST be assigned  a  routable  IP
     address.


Security
     In the process of authenticating and authorizing Fred's session, it
     may be desirable to provide protection against a variety  of  secu-
     rity threats.


4.3.  Accounting Subsystem

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



Aboba & Zorn                                                    [Page 6]


INTERNET-DRAFT            Roaming Requirements                April 1998


5.  Roaming Requirements


5.1.  Phonebook requirements


5.1.1.  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  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, as well as the integrity  of  the  newly
     produced phone book after updating it.

Lightweight transfers
     Since  the  client machine can be a low-end PC, the update protocol
     SHOULD 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.


5.1.2.  Phone book format


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



Aboba & Zorn                                                    [Page 7]


INTERNET-DRAFT            Roaming Requirements                April 1998


     the available phone numbers.

Provider attributes
     In addition to providing information relating to a given phone num-
     ber,  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 num-
     ber,  and service provider, the phone book MUST provide information
     relevant to configuration of the service. These attributes are nec-
     essary to provide the client with information relating to the oper-
     ation 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  accomo-
     date 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.


5.2.  Authentication requirements


5.2.1.  Connection Management

Given  the  current popularity and near ubiquity of PPP, a roaming stan-
dard 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 will 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 will not be required as part of a roaming standard.






Aboba & Zorn                                                    [Page 8]


INTERNET-DRAFT            Roaming Requirements                April 1998


5.2.2.  Identification

A roaming standard MUST provide a standardized format for the userID and
realm  presented  to  the NAS. This userID is also commonly known as the
Network Access Identifier (NAI).


5.2.3.  Verification of Identity


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  suffi-
     cient  scalability  to  allow for the formation of roaming associa-
     tions with thousands of ISP members.


5.2.4.  NAS Configuration/Authorization

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


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

Layer 3 tunneling protocols
     Layer-3 tunneling protocols as embodied in Mobile IP, described  in
     [8],  hold great promise for providing "live", transparent mobility



Aboba & Zorn                                                    [Page 9]


INTERNET-DRAFT            Roaming Requirements                April 1998


     on the part of mobile nodes  on  the  Internet.   Therefore,  proxy
     implementations  MUST  NOT preclude the provision of Mobile IP For-
     eign Agents or other Mobile IP functionality on the part of service
     providers.


5.2.6.  Security


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  can be accomplished through support of
     network layer (IPSEC) or transport layer security (TLS).

End-to-end security
     As policy implementation and attribute editing are common in  roam-
     ing systems, it is often necessary for proxies 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.


5.3.  Accounting requirements


Real-time accounting
     In today's roaming implementations, real-time accounting is a prac-
     tical  necessity  in order to support fraud detection and risk man-
     agement. As a result, a roaming standard MUST provide  support  for
     real-time accounting.

End-to-end security
     Proxies  in  a  roaming system SHOULD NOT modify accounting packets
     before forwarding them; however, modifications may be necessary  in
     some situations.  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



Aboba & Zorn                                                   [Page 10]


INTERNET-DRAFT            Roaming Requirements                April 1998


     confidentiality   and  integrity  protection  on  an  attribute-by-
     attribute basis.  However, non-repudiation is NOT a requirement for
     a roaming standard.

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. As a result,
     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 by Internet Service Providers to determine the user's
     bill.  Since these metrics 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  met-
     rics as well as vendor-specific metrics.


6.  Security Considerations

Security issues are discussed throughout this document.


7.  References


[1]  Aboba,  B., et. al., "Review of Roaming Implementations", RFC 2194,
     September 1997

[2]  Rigney, C., et. al., "Remote Authentication Dial  In  User  Service
     (RADIUS)", RFC 2138, April 1997

[3]  Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.

[4]  Bradner,  S.,  "Key  words  for use in RFCs to Indicate Requirement
     Levels", RFC 2119, March 1997

[5]  Zorn, G., "RADIUS Attributes for Tunnel Protocol  Support",  draft-
     ietf-radius-tunnel-auth-04.txt (work in progress), November 1997

[6]  Aboba, B. and Zorn, G., "Implementation of PPTP/L2TP Mandatory Tun-
     neling via RADIUS",  draft-ietf-radius-tunnel-imp-03.txt  (work  in
     progress), September 1997





Aboba & Zorn                                                   [Page 11]


INTERNET-DRAFT            Roaming Requirements                April 1998


[7]  Rigney, C. and Willats, W., "RADIUS Extensions", draft-ietf-radius-
     ext-01.txt (work in progress), December 1997

[8]  Perkins, C., "IP Mobility Support", RFC 2002, October 1996


8.  Acknowledgements

Thanks   to   Pat   Calhoun    (pcalhoun@eng.sun.com),    Butch    Anton
(butch@ipass.com), Dr. Thomas Pfenning (thomaspf@microsoft.com), and Don
Dumitru (dondu@microsoft.com) for many useful discussions of this  prob-
lem space.


9.  Chairs' Addresses

The  Roaming  Operations  Working Group can be contacted via the current
chairs:

   Pat Calhoun
   Sun Microsystems
   901 San Antonio Road
   Palo Alto, CA 94303

   Phone: +1 650 960 1300
   Email: pcalhoun@toast.net


   Glen Zorn
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052

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


10.  Authors' Addresses

Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

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





Aboba & Zorn                                                   [Page 12]


INTERNET-DRAFT            Roaming Requirements                April 1998


Glen Zorn
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

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


11.  Expiration Date

This memo is filed as <draft-ietf-roamops-roamreq-09.txt> and expires on
October 10, 1998.






































Aboba & Zorn                                                   [Page 13]