rfc2477.txt

<VC++网络游戏建摸与实现>源代码


RFC 2477              Evaluating Roaming Protocols          January 1999


   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
   number, and service provider, the phone book MUST provide information
   relevant to configuration of the service.  These attributes are
   necessary to provide the client with information relating to the
   operation 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
   accomodate 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.

4.2.  Authentication requirements

4.2.1.  Connection Management

   Given the current popularity and near ubiquity of PPP, a roaming
   standard 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 may 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 SHOULD NOT be part of a roaming standard.

4.2.2.  Identification

   A roaming standard MUST provide a standardized format for the userID
   and realm presented to the NAS.






Aboba & Zorn                 Informational                      [Page 7]

RFC 2477              Evaluating Roaming Protocols          January 1999


4.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 sufficient scalability to allow for the formation of
      roaming associations with thousands of ISP members.

   RADIUS Support
      Given the current popularity and near ubiquity of RADIUS [2,3] as
      an authentication, authorization and accounting solution, a
      roaming standard MUST be able to incorporate RADIUS-enabled
      devices within the roaming architecture. It is expected that this
      will be accomplished by development of gateways between RADIUS and
      the roaming standard authentication, authorization, and accounting
      protocol.

4.2.4.  NAS Configuration/Authorization

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

4.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 [5], hold
      great promise for providing "live", transparent mobility on the



Aboba & Zorn                 Informational                      [Page 8]

RFC 2477              Evaluating Roaming Protocols          January 1999


      part of mobile nodes on the Internet.  Therefore, a roaming
      standard MUST NOT preclude the provisioning of Mobile IP Foreign
      Agents or other Mobile IP functionality on the part of service
      providers.

4.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 MAY be accomplished through
      support of network layer security (IPSEC) [6].

   End-to-end security
      As policy implementation and attribute editing are common in
      roaming systems, proxies may need 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.

4.3.  Accounting requirements

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

   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.
      Therefore, 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 to determine the user's bill.  Since these metrics



Aboba & Zorn                 Informational                      [Page 9]

RFC 2477              Evaluating Roaming Protocols          January 1999


      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 metrics as well as
      vendor-specific metrics.

5.  References

   [1] Aboba, B., Lu, J., Alsop, J., Ding, J. and W. Wang, "Review of
       Roaming Implementations", RFC 2194, September 1997.

   [2] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "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", BCP 14, RFC 2119, March 1997.

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

   [6] Kent, S. and R. Atkinson, "Security Architecture for the Internet
       Protocol", RFC 2401, November 1998.

   [7] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
       Protocol (EAP)", RFC 2284, March 1998.

   [8] Simpson, W., "PPP Challenge Handshake Authentication Protocol
       (CHAP)", RFC 1994, August 1996.

   [9] Lloyd, B. and Simpson, W., "PPP Authentication Protocols", RFC
       1334, October 1992.

   [10] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
        1661, July 1994.

6.  Security Considerations

   This document, being a requirements document, does not have any
   security concerns.  The security requirements on protocols to be
   evaluated using this document are mainly described in section 5.2.

7.  Acknowledgements

   Thanks to Pat Calhoun ([e-mail]), Butch Anton
   ([e-mail]) and John Vollbrecht ([e-mail]) for many useful
   discussions of this problem space.




Aboba & Zorn                 Informational                     [Page 10]

RFC 2477              Evaluating Roaming Protocols          January 1999


8.  Authors' Addresses

   Bernard Aboba
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052

   Phone: [phone]
   EMail: [e-mail]


   Glen Zorn
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052

   Phone: [phone]
   EMail: [e-mail]

































Aboba & Zorn                 Informational                     [Page 11]

RFC 2477              Evaluating Roaming Protocols          January 1999


9.  Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Aboba & Zorn                 Informational                     [Page 12]