rfc2194.txt

RFC 的详细文档！

   optional attributes, so that there is no way for the proxy to take
   guidance from the server.

   Conflicts over session or idle timeouts may result if since both the
   local and home ISP feel the need to adjust these parameters.  While
   the home ISP may wish to adjust the parameter to match the user's
   software, the local ISP may wish to adjust it to match its own
   service policy. As long as the desired parameters do not differ too
   greatly, a compromise is often possible.

7.9.  Address assignment and routing

   While the Connection Manager software supports both static and
   dynamic address assignment, in the MSN implementation, all addresses
   are dynamically assigned.

   However, selected partners also offer LAN connectivity to their
   customers, usually via static address assignment. However, these
   accounts do not have roaming privileges since no mechanism has been
   put in place for allowing these static routes to move between
   providers.

   Users looking to do LAN roaming between providers are encouraged to
   select a router supporting Network Address Translation (NAT). NAT
   versions implemented in several low-end routers are compatible with
   the dynamic addressing used on MSN, as well as supporting DHCP on the
   LAN side.

7.10.  Security

   The RADIUS proxy/server implementation does not support token cards
   or tunneling protocols.





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


7.11.  Accounting

   In the MSN roaming implementation, the accounting data exchange
   process is specified in terms of an accounting record format, and a
   method by which the records are transferred from the partners to MSN,
   which acts as the settlement agent.  Defining the interaction in
   terms of record formats and transfer protocols implies that the
   partners do not communicate with the settlement agent using NAS
   accounting protocols.  As a result, accounting protocol
   interoperability is not be required.

   However, for this advantage to be fully realized, it is necessary for
   the accounting record format to be extensible.  This makes it more
   likely that the format can be adapted for use with the wide variety
   of accounting protocols in current use (such as SNMP, syslog, RADIUS,
   and TACACS+), as well as future protocols. After all, if the record
   format cannot express the metrics provided by a particular partner's
   accounting protocol, then the record format will not be of much
   usefor a heterogeneous roaming consortium.

7.11.1.  Accounting record format

   The Microsoft RADIUS proxy/server supports the ability to customize
   the accounting record format, and it is expected that some ISPs will
   make use of this capability. However for those who want to use it
   "off the shelf" a default accounting record format is provided. The
   accounting record includes information provided by RADIUS:

      User Name (String; the user's ID, including prefix or suffix)
      NAS IP address (Integer; the IP address of the user's NAS)
      NAS Port (Integer; identifies the physical port on the NAS)
      Service Type (Integer; identifies the service provided to the user)
      NAS Identifier (Integer; unique identifier for the NAS)
      Status Type (Integer; indicates session start and stop,
        as well as accounting on and off)
      Delay Time (Integer; time client has been trying to send)
      Input Octets (Integer; in stop record, octets received from port)
      Output Octets (Integer; in stop record, octets sent to port)
      Session ID (Integer; unique ID linking start and stop records)
      Authentication (Integer; indicates how user was authenticated)
      Session Time (Integer; in stop record, seconds of received service)
      Input Packets (Integer; in stop record, packets received from port)
      Output Packets (Integer; in stop record, packets sent to port)
      Termination Cause (Integer; in stop record, indicates termination cause)
      Multi-Session ID (String; for linking of multiple related sessions)
      Link Count (Integer; number of links up when record was generated)
      NAS Port Type (Integer; indicates async vs. sync ISDN, V.120, etc.)




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


   However, since this default format is not extensible, it cannot
   easily be adapted to protocols other than RADIUS, services other than
   dialup (i.e. dedicated connections) or rated events (i.e.  file
   downloads).  This is a serious limitation, and as a result, customers
   have requested a more general accounting record format.

7.11.2.  Transfer mechanism

   Prior to being transferred, the accounting records are compressed so
   as to save bandwidth.  The transfer of accounting records is handled
   via FTP, with the transfer being initiated by the receiving party,
   rather than by the sending party.  A duplicate set of records is kept
   by the local ISP for verification purposes.

8.  Merit Network Implementation

8.1.  Overview

   MichNet is a regional IP backbone network operated within the state
   of Michigan by Merit Network, Inc., a nonprofit corporation based in
   Ann Arbor, Michigan. Started in 1966, MichNet currently provides
   backbone level Internet connectivity and dial-in IP services to its
   member and affiliate universities, colleges, K-12 schools, libraries,
   government institutions, other nonprofit organizations, and
   commercial business entities.

   As of May 1, 1997, MichNet had 11 members and 405 affiliates.  Its
   shared dial-in service operated 133 sites in Michigan and one in
   Washington, D.C, with 4774 dial-in lines.  Additional dial-in lines
   and sites are being installed daily.

   MichNet also provides national and international dial-in services to
   its members and affiliates through an 800 number and other external
   services contracting with national and global service providers.

   The phone numbers of all MichNet shared dial-in sites are published
   both on the Merit web site and in the MichNet newsletters. Merit also
   provides links to information about the national and international
   service sites through their respective providers' web sites.  Such
   information can be found at http://www.merit.edu/mich-
   net/shared.dialin/.

8.1.1.  MichNet State-Wide Shared Dial-In Services

   Each MichNet shared dial-in service site is owned and maintained by
   either Merit or by a member or affiliate organization. All sites must
   support PPP and Telnet connections.




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


   Each organization participating in the shared dial-in service is
   assigned a realm-name.  Typically the realm-name resembles a fully
   qualified domain name. Users accessing the shared dial-in service
   identify themselves by using a MichNet AccessID which consists of
   their local id concatenated with "@" followed by the realm-name -
   e.g.  user@realm

   Merit operates a set of Authentication, Authorization and Accounting
   (AAA) servers supporting the RADIUS protocol which are called core
   servers.  The core servers support all the dial-in service sites and
   act as proxy servers to other AAA servers running at the
   participating organizations. For security reasons, Merit staff run
   all core servers; in particular, the user password is in the clear
   when the proxy core server decodes an incoming request and then re-
   encodes it and forwards it out again,

   The core servers also enforce a common policy among all dial-in
   servers.  The most important policy is that each provider of access
   must make dial-in ports available to others when the provider's own
   users do not have a need for them. To implement this policy, the
   proxy server distinguishes between realms that are owners and realms
   that are guests.

   One piece of the policy determining whether the provider's
   organization has need of the port, is implemented by having the proxy
   core server track the realms associated with each of the sessions
   connected at a particular huntgroup. If there are few ports available
   (where few is determined by a formula) then guests are denied access.
   Guests are also assigned a time limit and their sessions are
   terminated after some amount of time (currently one hour during prime
   time, two hours during non-prime time).

   The other part of the policy is to limit the number of guests that
   are allowed to connect.  This is done by limiting the number of
   simultaneous guest sessions for realms.  Each realm is allocated a
   number of "simultaneous access tokens" - SATs.  When a guest session
   is authorized the end server for the realm decrements the count of
   available SATs, and when the session is terminated the count of SATs
   is incremented.  A Merit specific attribute is added to the request
   by the core if the session will be a "guest" and will require a SAT.
   The end server must include a reply with an attribute containing the
   name of the "token pool" from which the token for this session is
   taken.  The effect of this is to limit the number of guests connected
   to the network to the total number of tokens allocated to all realms.







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


   Each realm is authenticated and authorized by its own AAA server. The
   proxy core servers forward requests to the appropriate server based
   on a configuration file showing where each realm is to be
   authenticated.  Requests from realms not in the configuration are
   dropped.

   The Merit AAA server software supports this policy.  Merit provides
   this software to member and affiliate organizations. The software is
   designed to work with many existing authentication servers, such as
   Kerberos IV, UNIX password, TACACS, TACACS+, and RADIUS.  This
   enables most institutions to utilize the authentication mechanism
   they have in place.

8.1.2.  MichNet National and International Dial-In Services

   In addition to the MichNet shared dial-in service, Merit also
   provides access from locations outside of Michigan by interconnecting
   with other dial-in services. These services are typically billed by
   connect time. Merit acts as the accounting agent between its member
   and affiliate organizations and the outside service provider.

   The services currently supported are a national 800 number and
   service via the ADP/Autonet dial-in network. Connection with
   IBM/Advantis is being tested, and several other service interconnects
   are being investigated.

   Calls placed by a Merit member/affiliate user to these external
   dial-in services are authenticated by having each of those services
   forward RADIUS authentication requests and accounting messages to a
   Merit proxy core server. The core forwards the requests to the
   member/affiliate server for approval. Session records are logged at
   the Merit core server and at the member/affiliate erver. Merit bills
   members/affiliates monthly, based on processing of the accounting
   logs. The members and affiliates are responsible for rebilling their
   users.

   The Merit AAA software supports the ability to request positive
   confirmation of acceptance of charges, and provides tools for
   accumulating and reporting on use by realm and by user.

8.2.  Authentication and Authorization

   Authentication of a Telnet session is supported using the traditional
   id and password method, with the id being a MichNet AccessID of the
   form user@realm, while a PPP session may be authenticated either
   using an AccessID and password within a script, or using PAP.
   Support for challenge/response authentication mechanisms using EAP is
   under development.



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


   When a user dials into a MichNet shared dial-in port, the NAS sends
   an Access-Request to a core AAA server using the RADIUS protocol.
   First the core server applies any appropriate huntgroup access
   policies to the request. If the Request fails the policy check, an
   Access-Reject is returned to the NAS.  Otherwise, the core server
   forwards it to the user's home authentication server according to the
   user's realm.  The home authentication server authenticates and
   authorizes the access request.  An Access-Accept or Access-Reject is
   sent back to the core server.  If an Access-Accept is sent, the home
   server will create a dial-in session identifier which is unique to
   this session and insert it in a Class attribute in the Access-Accept.
   The core server looks at the request and the response from the home
   server again and decides either to accept or reject the request.
   Finally, the core server sends either an Access-Accept or Access-
   Reject to the NAS.

   When a user dials into a contracted ISP's huntgrup (MichNet National
   and International Service), the ISP sends a RADIUS access request to
   a Merit core server. The rest of the authentication and authorization
   path is the same as in the shared dial-in service, except that no
   huntgroup access policy is applied but a Huntgroup-Service attribute
   is sent to the home authentication server with its value being the
   name of the service, and a copy of the attribute must be returned by
   the home server with a flag appended to the original value to
   indicate a positive authorization of user access to the specified
   service.

   The MichNet shared dial-in service typically requires authorization
   of some sort, for example, a user dialing into a huntgroup as a guest
   must be authorized with a token from the user's realm. Participating
   institutions have control in defin