rfc2194.txt

RFC 的详细文档！

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
        flags in the phone book)
      The dial-up connection properties configuration
        (this is the DUN connectoid name)

   The phone book file is a comma delimited ASCII file containing the
   following data:

      Unique number identifying a particular record (Index)
      Country ID
      A zero-base index into the region file
      City
      Area code
      Local phone number
      Minimum Speed
      Maximum speed
      Capability Flags:
        Bit 0: 0=Toll, 1=Toll free
        Bit 1: 0=X25, 1=IP
        Bit 2: 0=Analog, 1=No analog support
        Bit 3: 0=no ISDN support, 1=ISDN
        Bit 4: 0
        Bit 5: 0
        Bit 6: 0=No Internet access, 1=Internet access
        Bit 7: 0=No signup access, 1=Signup access
        Bit 8-31: reserved
      The filename of the dialup network file
        (typically refers to a script associated with the number)








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


   A sample phone book file is shown below:

      65031,1,1,Aniston,205,5551212,2400,2400,1,0,myfile
      200255,1,1,Auburn/Opelika,334,5551212,9600,28800,0,10,
      200133,1,1,Birmingham,205,5551212,9600,28800,0,10,
      130,1,1,Birmingham,205,3275411,9600,14400,9,0,yourfile
      65034,1,1,Birmingham,205,3285719,9600,14400,1,0,myfile

7.2.3.  Additional attributes

   As described previously, it is likely that some ISPs will require
   additional phone number attributes or provider information beyond
   that supported in the default phone book format.  Attributes of
   interest may vary between providers, or may arise as a result of the
   introduction of new technologies.  As a result, the set of phone
   number attributes is likely to evolve over time, and extensibility in
   the phone book format is highly desirable.

   For example, in addition to the attributes provided in the default
   phone book, the following additional attributes have been requested
   by customers:

      Multicast support flag
      External/internal flag (to differentiate display between the
           "internal" or "other" list box)
      Priority  (for control of presentation order)
      Modem protocol capabilities (V.34, V.32bis, etc.)
      ISDN protocol capabilities (V.110, V.120, etc.)
      No password flag (for numbers using telephone-based billing)
      Provider name

7.2.4.  Addition of information on providers

   The default phone book does not provide a mechanism for display of
   information on the individual ISPs within the roaming consortium,
   only for the consortium as a whole. For example, the provider icons
   (big and little) are included in the service profile. The service
   description information is expected to contain the customer support
   number.  However, this information cannot be provided on an
   individual basis for each of the members of a roaming consortium.
   Additional information useful on a per-provider basis would include:

      Provider voice phone number
      Provider icon
      Provider fax phone number
      Provider customer support phone number





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


7.3.  Phone number exchange

   Currently phone number exchange is not supported by the phone book
   server. As a result, in the MSN implementation, phone number exchange
   is handled manually.  As new POPs come online, the numbers are
   forwarded to MSN, which tests the numbers and approves them for
   addition to the phone book server. Updated phone books are produced
   and loaded on the phone book server on a weekly basis.

7.4.  Phone book compilation

   The Phone Book Manager tool was created in order to make it easier
   for the access partners to create and update their phone books. It
   supports addition, removal, and editing of phone numbers, generating
   both a new phone book, as well as associated difference files.

   With version 1 of the Phone Book Administration tool, phone books are
   compiled manually, and represent a concatenation of available numbers
   from all partners, with no policy application.  With version 1, the
   updates are prepared by the partners and forwarded to MSN, which
   tests the numbers and approves them for addition to the phone book.
   The updates are then concatenated together to form the global update
   file.

   The new version of the Phone Book Administration tool automates much
   of the phone book compilation process, making it possible for phone
   book compilation to be decentralized with each partner running their
   own phone book server. Partners can then maintain and test their
   individual phone books and post them on their own Phone Book Server.

7.5.  Phone book update

   There is a mechanism to download phone book deltas, as well as to
   download arbitrary executables which can perform more complex update
   processing.  Digital signatures are only used on the downloading of
   executables, since only these represent a security threat - the
   Connection Manager client does not check for digital signatures on
   deltas because bogus deltas can't really cause any harm.


   The Connection Manager updates the phone book each time the user logs
   on.  This is accomplished via an HTTP GET request to the phone book
   server. When the server is examining the request, it can take into
   account things like the OS version on the client, the language on the
   client, the version of Connection Manager on the client, and the
   version of the phone book on the client, in order to determine what
   it wants to send back.




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


   In the GET response, the phone book server responds with the
   difference files necessary to update the client's phone book to the
   latest version. The client then builds the new phone book by
   successively applying these difference files.  This process results
   in the update of the entire phone book, and is simple enough to allow
   it to be easily implemented on a variety of HTTP servers, either as a
   CGI script or (on NT) as an ISAPI DLL.

   The difference files used in the default phone book consist of a
   list of phone book entries, each uniquely identified by their index
   number.  Additions consist of phone book entries with all the
   information filed in;  deletions are signified by entries with all
   entries zeroed out. A sample difference file is shown below:

      65031,1,1,Aniston,205,5551212,2400,2400,1,0,myfile
      200255,1,1,Auburn/Opelika,334,5551212,9600,28800,0,10,
      200133,0,0,0,0,0,0,0,0,0
      130,1,1,Birmingham,205,5551211,9600,14400,9,0,yourfile
      65034,1,1,Birmingham,205,5551210,9600,14400,1,0,myfile


7.6.  Connection management

   The Connection Manager can support any protocol which can be
   configured via use of Windows Dialup Networking, including PPP and
   SLIP running over IP.  The default setting is for the IP address as
   well as the DNS server IP address to be assigned by the NAS. The DNS
   server assignment capability is described in [1].

7.7.  Authentication

   The Connection Manager client and RADIUS proxy/server both support
   suffix style notation (i.e.  "[e-mail]"), as well as a prefix
   notation ("MSN/aboba").

   The prefix notation was developed for use with NAS devices with small
   maximum userID lengths.  For these devices the compactness of the
   prefix notation significantly increases the number of characters
   available for the userID field.  However, as an increasing number of
   NAS devices are now supporting 253 octet userIDs (the maximum
   supported by RADIUS) the need for prefix notation is declining.

   After receiving the userID from the Connection Manager client, the
   NAS device passes the userID/domain and password information (or in
   the case of CHAP, the challenge and the response) to the RADIUS






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


   proxy. The RADIUS proxy then checks if the domain is authorized for
   roaming by examining a static configuration file. If the domain is
   authorized, the RADIUS proxy then forwards the request to the
   appropriate RADIUS server. The domain to server mapping is also made
   via a static configuration file.

   While static configuration files work well for small roaming
   consortia, for larger consortia static configuration will become
   tedious.  Potentially more scalable solutions include use of DNS SRV
   records for the domain to RADIUS server mapping.


7.8.  NAS configuration/authorization

   Although the attributes returned by the home RADIUS server may make
   sense to home NAS devices, the local NAS may be configured
   differently, or may be from a different vendor.  As a result, it may
   be necessary for the RADIUS proxy to edit the attribute set returned
   by the home RADIUS server, in order to provide the local NAS with the
   appropriate configuration information.  The editing occurs via
   attribute discard and insertion of attributes by the proxy.

   Alternatively, the home RADIUS server may be configured not to return
   any network-specific attributes, and to allow these to be inserted by
   the local RADIUS proxy.

   Attributes most likely to cause conflicts include:

      Framed-IP-Address Framed-IP-Netmask Framed-Routing Framed-Route
      Filter-Id Vendor-Specific Session-Timeout Idle-Timeout
      Termination-Action

   Conflicts relating to IP address assignment and routing are very
   common.  Where dynamic address assignment is used, an IP address pool
   appropriate for the local NAS can be substituted for the IP address
   pool designated by the home RADIUS server.

   However, not all address conflicts can be resolved by editing.  In
   some cases, (i.e., assignment of a static network address for a LAN)
   it may not be possible for the local NAS to accept the home RADIUS
   server's address assignment, yet the roaming hosts may not be able to
   accept an alternative assignment.

   Filter IDs also pose a problem. It is possible that the local NAS may
   not implement a filter corresponding to that designated by the home
   RADIUS server. Even if an equivalent filter is implemented, in order
   to guarantee correct operation, the proxy's configuration must track
   changes in the filter configurations of each of the members of the



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


   roaming consortium.  In practice this is likely to be unworkable.
   Direct upload of filter configuration is not a solution either,
   because of the wide variation in filter languages supported in
   today's NAS devices.

   Since by definition vendor specific attributes have meaning only to
   devices created by that vendor, use of these attributes is
   problematic within a heterogeneous roaming consortium. While it is
   possible to edit these attributes, or even to discard them or allow
   them to be ignored, this may not always be acceptable. In cases where
   vendor specific attributes relate to security, it may not be
   acceptable for the proxy to modify or discard these attributes; the
   only acceptable action may be for the local NAS to drop the user.
   Unfortunately, RADIUS does not distinguish between mandatory and