rfc2977.txt

RFC 的详细文档！

   there is no need for an AAA protocol or infrastructure to interact
   with the AAAH. The resulting simple configuration is illustrated in
   figure 5.

   In this simplified model, we may consider that the role of the AAAH
   is taken over either by a national government (in the case of a cash
   payment), or by a card authorization service if payment is by credit
   card, or some such authority acceptable to all parties.  Then, the
   AAAL expects those external authorities to guarantee the value
   represented by the client's payment credentials (cash or credit).
   There are likely to be other cases where clients are granted access
   to local resources, or access to the Internet, without any charges at
   all.  Such configurations may be found in airports and other common

                      +-------------------------+
                      |  +------+    +------+   |
                      |  |      |    |      |   |
                      |  |  HA  +----+ AAAL |   |
                      |  |      |    |      |   |
                      |  +--+---+    +----+-+   |
                      |     |             |     |
                      |     +- - - - - +  |     |
           +------+   |              +-+--+-+   |
           |      |   |              |      |   |
           |  MN  +- -|- - - - - - - +  FA  |   |
           |      |   | Local Domain |      |   |
           +------+   |              +------+   |
                      +-------------------------+

       Figure 5: Local Payment for Local Mobile IP services

   areas where business clients are likely to spend time.  The service
   provider may find sufficient reward in the goodwill of the clients,
   or from advertisements displayed on Internet portals that are to be
   used by the clients.  In such situations, the AAAL SHOULD still
   allocate a home agent, appropriate keys, and the mobile node's home
   address.




Glass, et al.                Informational                     [Page 17]

RFC 2977               Mobile IP AAA Requirements           October 2000


5.5. Fast Handover

   Since the movement from coverage area to coverage area may be
   frequent in Mobile IP networks, it is imperative that the latency
   involved in the handoff process be minimized.  See, for instance, the
   Route Optimization document [15] for one way to do this using Binding
   Updates.  When the mobile node enters a new visited subnet, it would
   be desirable for it to provide the previous foreign agent's NAI.  The
   new FA can use this information to either contact the previous FA to
   retrieve the KDC session key information, or it can attempt to
   retrieve the keys from the AAAL.  If the AAAL cannot provide the
   necessary keying information, the request will have to be sent to the
   mobile node's AAAH to retrieve new keying information.  After initial
   authorization, further authorizations SHOULD be done locally within
   the Local Domain.

   When a MN moves into a new foreign subnet as a result of a handover
   and is now served by a different FA, the AAAL in this domain may
   contact the AAAL in the domain that the MN has just been handed off
   from to verify the authenticity of the MN and/or to obtain the
   session keys.  The new serving AAAL may determine the address of the
   AAAL in the previously visited domain from the previous FA NAI
   information supplied by the MN.

6. Broker Model

   The picture in Figure 1 shows a configuration in which the local and
   the home authority have to share trust.  Depending on the security
   model used, this configuration can cause a quadratic growth in the
   number of trust relationships, as the number of AAA authorities (AAAL
   and AAAH) increases.  This has been identified as a problem by the
   roamops working group [3], and any AAA proposal MUST solve this
   problem.  Using brokers solves many of the scalability problems
   associated with requiring direct business/roaming relationships
   between every two administrative domains.  In order to provide
   scalable networks in highly diverse service provider networks in
   which there are many domains (e.g., many service providers and large
   numbers of private networks), multiple layers of brokers MUST be
   supported for both of the broker models described.

   Integrity or privacy of information between the home and serving
   domains may be achieved by either hop-by-hop security associations or
   end-to-end security associations established with the help of the
   broker infrastructure.  A broker may play the role of a proxy between
   two administrative domains which have security associations with the
   broker, and relay AAA messages back and forth securely.





Glass, et al.                Informational                     [Page 18]

RFC 2977               Mobile IP AAA Requirements           October 2000


   Alternatively, a broker may also enable the two domains with which it
   has associations, but the domains themselves do not have a direct
   association, in establishing a security association, thereby
   bypassing the broker for carrying the messages between the domains.
   This may be established by virtue of having the broker relay a shared
   secret key to both the domains that are trying to establish secure
   communication and then have the domains use the keys supplied by the
   broker in setting up a security association.

   Assuming that AAAB accepts responsibility for payment to the serving
   domain on behalf of the home domain, the serving domain is assured of
   receiving payments for services offered.  However, the redirection
   broker will usually require a copy of authorization messages from the
   home domain and accounting messages from the serving domain, in order
   for the broker to determine if it is willing to accept responsibility
   for the services being authorized and utilized.  If the broker does
   not accept such responsibility for any reason, then it must be able
   to terminate service to a mobile node in the serving network.  In the
   event that multiple brokers are involved, in most situations all
   brokers must be so copied.  This may represent an additional burden
   on foreign agents and AAALs.

   Though this mechanism may reduce latency in the transit of messages
   between the domains after the broker has completed its involvement,
   there may be many more messages involved as a result of additional
   copies of authorization and accounting messages to the brokers
   involved.  There may also be additional latency for initial access to
   the network, especially when a new security association needs to be
   created between AAAL and AAAH (for example, from the use of ISAKMP).
   These delays may become important factors for latency-critical
   applications.




















Glass, et al.                Informational                     [Page 19]

RFC 2977               Mobile IP AAA Requirements           October 2000


                Local Domain                        Home Domain
              +--------------+               +----------------------+
              |   +------+   |   +------+    |   +------+           |
              |   |      |   |   |      |    |   |      |           |
              |   | AAAL +-------+ AAAB +--------+ AAAH |           |
              |   |      |   |   |      |    |   |      |           |
              |   +------+   |   +------+    |   +------+           |
              |       |      |               |                      |
              |       |      |               +----------------------+
   +------+   |   +---+--+   |
   |      |   |   |      |   |       C    =  client
   |   C  +- -|- -+   A  |   |       A    =  attendant
   |      |   |   |      |   |       AAAL =  local authority
   +------+   |   +------+   |       AAAH =  home authority
              |              |       AAAB =  broker authority
              +--------------+

                Figure 6: AAA Servers Using a Broker

   The AAAB in figure 6 is the broker's authority server.  The broker
   acts as a settlement agent, providing security and a central point of
   contact for many service providers and enterprises.

   The AAAB enables the local and home domains to cooperate without
   requiring each of the networks to have a direct business or security
   relationship with all the other networks.  Thus, brokers offer the
   needed scalability for managing trust relationships between otherwise
   independent network domains.  Use of the broker does not preclude
   managing separate trust relationships between domains, but it does
   offer an alternative to doing so.  Just as with the AAAH and AAAL
   (see section 5), data specific to Mobile IP control messages MUST NOT
   be processed by the AAAB.  Any credentials or accounting data to be
   processed by the AAAB must be present in AAA message units, not
   extracted from Mobile IP protocol extensions.

   The following requirements come mostly from [2], which discusses use
   of brokers in the particular case of authorization for roaming dial-
   up users.

   -  allowing management of trust with external domains by way of
      brokered AAA.
   -  accounting reliability.  Accounting data that traverses the
      Internet may suffer substantial packet loss.  Since accounting
      packets may traverse one or more intermediate authorization points
      (e.g., brokers), retransmission is needed from intermediate points
      to avoid long end-to-end delays.





Glass, et al.                Informational                     [Page 20]

RFC 2977               Mobile IP AAA Requirements           October 2000


   -  End to End security.  The Local Domain and Home Domain must be
      able to verify signatures within the message, even though the
      message is passed through an intermediate authority server.
   -  Since the AAAH in the home domain MAY be sending sensitive
      information, such as registration keys, the broker MUST be able to
      pass encrypted data between the AAA servers.

   The need for End-to-End security results from the following attacks
   which were identified when brokered operation uses RADIUS [16] (see
   [2] for more information on the individual attacks):

      + Message editing
      + Attribute editing
      + Theft of shared secrets
      + Theft and modification of accounting data
      + Replay attacks
      + Connection hijacking
      + Fraudulent accounting

   These are serious problems which cannot be allowed to persist in any
   acceptable AAA protocol and infrastructure.

7. Security Considerations

   This is a requirements document for AAA based on Mobile IP.  Because
   AAA is security driven, most of this document addresses the security
   considerations AAA MUST make on behalf of Mobile IP.  As with any
   security proposal, adding more entities that interact using security
   protocols creates new administrative requirements for maintaining the
   appropriate security associations between the entities.  In the case
   of the AAA services proposed however, these administrative
   requirements are natural, and already well understood in today's
   Internet because of experience with dial up network access.

8. IPv6 Considerations

   The main difference between Mobile IP for IPv4 and Mobile IPv6 is
   that in IPv6 there is no foreign agent.  The attendant function,
   therefore, has to be located elsewhere.  Logical repositories for
   that function are either at the local router, for stateless address
   autoconfiguration, or else at the nearest DHCPv6 server, for stateful
   address autoconfiguration.  In the latter case, it is possible that
   there would be a close relationship between the DHCPv6 server and the
   AAALv6, but we believe that the protocol functions should still be
   maintained separately.

   The MN-NAI would be equally useful for identifying the mobile node to
   the AAALv6 as is described in earlier sections of this document.



Glass, et al.                Informational                     [Page 21]

RFC 2977               Mobile IP AAA Requirements           October 2000


9. Acknowledgements

   Thanks to Gopal Dommety and Basavaraj Patil for participating in the
   Mobile IP subcommittee of the aaa-wg which was charged with
   formulating the requirements detailed in this document.  Thanks to N.
   Asokan for perceptive comments to the mobile-ip mailing list.  Some
   of the text of this document was taken from a draft co-authored by
   Pat Calhoun.  Patrik Flykt suggested text about allowing AAA home
   domain functions to be separated from the domain managing the home
   address of the mobile computer.

   The requirements in section 5.5 and section 3.1 were taken from a
   draft submitted by members of the TIA's TR45.6 Working Group.  We
   would like to acknowledge the work done by the authors of that draft:
   Tom Hiller, Pat Walsh, Xing Chen, Mark Munson, Gopal Dommety,
   Sanjeevan Sivalingham, Byng-Keun Lim, Pete McCann, Brent Hirschman,
   Serge Manning, Ray Hsu, Hang Koo, Mark Lipford, Pat Calhoun, Eric
   Jaques, Ed Campbell, and Yingchun Xu.

References

   [1]  Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
        2486, January 1999.

   [2]  Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
        Implementation in Roaming", RFC 2607, June 1999.

   [3]  Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming
        Protocols", RFC 2477, December 1998.

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

   [5]  Ramon Caceres and Liviu Iftode.  Improving the Performance of