rfc2194.txt

中、英文RFC文档大全打包下载完全版 .

   Accounting transactions are handled in the same way as authentication
   requests.  In addition to being logged at the i-Pass servers,



Aboba, et. al.               Informational                     [Page 11]

RFC 2194           Review of Roaming Implementations      September 1997


   accounting transactions are sent in real-time to the home ISP.  This
   is intended to allow ISPs to update users' credit limit information
   on a real-time basis (to the extent that this capability is supported
   by their billing and accounting systems).

   Settlement is performed monthly.  The settlement process involves
   calculating the costs associated with each individual session, and
   aggregating them for each ISP.  A net amount is then calculated which
   is either due from i-Pass to the ISP, or from the ISP to i-Pass,
   depending on the actual usage pattern.

   The following reports are supplied to member ISPs:

      A Monthly Statement showing summaries of usage, service provided,
      and any adjustments along with the net amount owing.

      A Call Detail Report showing roaming usage by the ISP's customers.

      A Service Provided report showing detailed usage of the ISP's
      facilities by remote users.

   The above reports are generated as ASCII documents and are
   distributed to i-Pass partners electronically, either by e-mail or
   from  a  secure area on the i-Pass web site. Hard-copy output is
   available on request.

   The Call Detail Report is also generated as a comma-delimited ASCII
   file suitable for import into the ISP's billing database. The Call
   Detail Report will normally be used by the ISP to generate end-user
   billing for roaming usage.

5.6.  Security

   All  transactions  between  ISPs  and the i-Pass servers are
   encrypted using the SSL protocol.  Public key certificates are
   verified at  both the  client  and  server. i-Pass issues these
   certificates and acts as the Cetificate Authority.

   Transactions are also verified based on a number of other criteria
   such as source IP address.

5.7.  Operations

   i-Pass operates several authentication server sites.  Each site
   consists of two redundant server systems located in secure facilities
   and "close" to the Internet backbone.  The authentication server
   sites are geographically distributed to minimize the possibility of
   failure due to natural disasters etc.



Aboba, et. al.               Informational                     [Page 12]

RFC 2194           Review of Roaming Implementations      September 1997


   i-Pass maintains a Network Operations Center in Mountain View which
   is staffed on a 7x24 basis.  Its functions include monitoring the i-
   Pass authentication servers, monitoring authentication servers
   located at partner facilities, and dealing with problem reports.

6.  ChinaNet implementation

   ChinaNet, owned by China Telecom, is China's largest Internet
   backbone.  Constructed by Asiainfo, a Dallas based system integration
   company, it has 31 backbone nodes in 31 Chinese provincial capital
   cities.  Each province is building its own provincial network, has
   its own dialup servers, and administers its own user base.

   In order to allow hinaNet users to be able to access nodes outside
   their province while traveling, a nationwide roaming system has been
   implemented.  The roaming system was developed by AsiaInfo, and is
   based on the RADIUS protocol.

6.1.  Phone number presentation

   Since China Telecom uses one phone number (163) for nationwide
   Internet access, most cities have the same Internet access number.
   Therefore a phone book is not currently required for the ChinaNet
   implementation. A web-based phone book will be added in a future
   software release in order to support nationwide ISP/CSP telephone
   numbers and HTTP server addresses.

6.2.  Connection management

   The current roaming client and server supports both PPP and SLIP.


6.3.  Address assignment and routing

   ChinaNet only supports dynamic IP address assignment for roaming
   users. In addition, static addresses are supported for users
   authenticating within their home province.

6.4.  Authentication

   When user accesses a local NAS, it provides its userID either as
   "username" or "username@realm".  The NAS will pass the userID and
   password to the RADIUS proxy/server.  If the "username" notation is
   used, the Radius proxy/server will assume that the user is a local
   user and will handle local authentication accordingly.  If "user-
   name@realm" is used, the RADIUS proxy/server will process it as a
   roaming request.




Aboba, et. al.               Informational                     [Page 13]

RFC 2194           Review of Roaming Implementations      September 1997


   When the RADIUS proxy/server handles a request from a roaming user,
   it will first check the cache to see if the user information is
   already stored there. If there is a cache hit, the RADIUS
   proxy/server do the local authentication accordingly.  If it does not
   find user information in its cache, it will act as a proxy,
   forwarding the authentication request to the home RADIUS server.
   When the home RADIUS server responds, the local server will forward
   the response to the NAS.  If the user is authenticated by the home
   server, the local RADIUS proxy will cache the user information for a
   period of time (3 days by default).

   Caching is used to avoid frequent proxying of requests and responses
   between the local RADIUS proxy and the home RADIUS server.  When the
   home RADIUS server sends back a valid authentication response, the
   local RADIUS proxy/server will cache the user information for a
   period of time (3 days by default).  When the user next authenticates
   directly against the home RADIUS server, the home RADIUS server will
   send a request to the local server or servers to clear the user's
   information from the cache.

6.4.1.  Extended hierarchy

   In some provinces, the local telecommunications administration
   Provincial ISP) further delegates control to county access nodes,
   creating another level of hierarchy. This is done to improve
   scalability and to avoid having the provincial ISP databases grow too
   large.  In the current implementation, each provincial ISP maintains
   its own central RADIUS server, including information on all users in
   the province, while county nodes maintain distributed RADIUS servers.
   For intra-province roaming requests the local RADIUS proxy/server
   will directly forward the request to the home RADIUS server.

   However, for inter-province roaming requests, the local RADIUS server
   does not forward the request directly to the home RADIUS server.
   Instead, the request is forwarded to the central provincial RADIUS
   server for the home province. This implementation is suitable only
   when county level ISPs do not mind combining and sharing their user
   information.  In this instance, this is acceptable, since all county
   level ISPs are part of China Telecom. In a future release, this
   multi-layer hierarchy will be implemented using multi-layer proxy
   RADIUS, in a manner more resembling DNS.

6.5.  Security

   Encryption is used between the local RADIUS proxy/server and the home
   RADIUS server. Public/Private key encryption will be supported in the
   next release. IP tunneling and token card support is under
   consideration.



Aboba, et. al.               Informational                     [Page 14]

RFC 2194           Review of Roaming Implementations      September 1997


6.6.  Accounting

   Accounting information is transferred between the local RADIUS
   accounting proxy/server and home RADIUS accounting server.  Every day
   each node sends a summary accounting information record to a central
   server in order to support nationwide settlement. The central server
   is run by the central Data Communication Bureau of China Telecom.
   Every month the central server sends the settlement bill to the
   provincial ISPs.

6.7.  Inter-ISP/CSP roaming

   ChinaNet supports both ISP and CSP (Content Service Provider) roaming
   on its system. For example, Shanghai Online, a Web-based commercial
   content service, uses RADIUS for authentication of ChinaNet users who
   do not have a Shanghai Online account. In order to support this, the
   Shanghai Online servers function as a RADIUS client authenticating
   against the home RADIUS server. When users access a protected
   document on the HTTP server, they are prompted to send a
   username/password for authentication. The user then responds with
   their userID in "user-name@realm" notation.

   A CGI script on the HTTP server then acts as a RADIUS authentication
   client, sending the request to the home RADIUS server. After the home
   RADIUS server responds, the CGI script passes the information to the
   local authentication agent. From this point forward, everything is
   taken care of by the local Web authentication mechanism.

7.  Microsoft implementation

   Microsoft's roaming implementation was originally developed in order
   to support the Microsoft Network (MSN), which now offers Internet
   access in seven countries: US, Canada, France, Germany, UK, Japan,
   and Australia.  In each of these countries, service is offered in
   cooperation with access partners.  Since users are able to connect to
   the access partner networks while maintaining a customer-vendor
   relationship with MSN, this implementation fits within the definition
   of roaming as used in this document.

7.1.  Implementation overview

   The first version of the Microsoft roaming software was deployed by
   the MSN partners in April, 1996.  This version included a Phone Book
   manager tool running under Windows 95, as well as a RADIUS
   server/proxy implementation running under Windows NT; TACACS+ is






Aboba, et. al.               Informational                     [Page 15]

RFC 2194           Review of Roaming Implementations      September 1997


   currently not supported.  Additional components now under development
   include a Connection Manager client for Windows 95 as well as an
   HTTP-based phone book server for Windows NT. The Phone Book manager
   tool is also being upgraded to provide for more automated phone book
   compilation.


7.2.  Phone number presentation

   The Connection Manager is responsible for the presentation and
   updating of phone numbers, as well as for dialing and making
   connections.  In order to select phone numbers, users are asked to
   select the desired country and region/state.  Phone numbers are then
   presented in the area selected.  The primary numbers are those from
   the users service provider which match the service type (Analog,
   ISDN, Analog & IDN), country and region/state selected. The other
   numbers (selected clicking on the More button) are those for other
   service providers that have a roaming agreement with the users
   service provider.

7.2.1.  Cost data

   Cost data is not presented to users along with the phone numbers.
   However, such information may be made available by other means, such
   as via a Web page.

7.2.2.  Default phone book format

   The Connection Manager supports the ability to customize the phone
   book format, and it is expected that many ISPs will make use of this
   capability. However, for those who wish to use it "off the shelf" a
   default phone book format is provided. The default phone book is
   comprised of several files, including:

      Service profile
      Phone Book
      Region file

   The service profile provides information on a given service, which
   may be an isolated Internet Service Provider, or may represent a
   roaming consortium. The service profile, which is in .ini file
   format, is comprised of the following information:

      The name of the service
      The filename of the service's big icon
      The filename of the service's little icon
      A description of the service
      The service phone book filename



Aboba, et. al.               Informational                     [Page 16]

RFC 2194           Review of Roaming Implementations      September 1997


      The service phone book version number
      The service regions file
      The URL of the service phone book server
      The prefix used by the service (i.e. "MSN/aboba")
      The suffix or domain used by the service (i.e. "[e-mail]")
      Whether the user name is optional for the service
      Whether the password is optional for the service
      Maximum length of the user name for the service
      Maximum length of the password for the service
      Information on service password handling (lowercase, mixed case, etc.)
      Number of redials for this service
      Delay between redials for this service
      References to other service providers that have roaming agreements
      The service profile filenames for each of the references
      Mask and match phone book filters for each of the references
        (these are 32 bit numbers that are applied against the capability