rfc2882.txt

gnu 的radius服务器很好用的

   authentication message (like the new RADIUS draft Service-Type =
   CallCheck) is emitted by the NAS upon call arrival. This message will
   contain only the Dialed-Number information in the Username field.
   The server receives the Access-Request messages and processes them
   against it's knowledge of the network state and the provisioned
   policies.

   An Access-Accept will be returned to the system to accept the call,
   and many also contain dynamic policy information and Virtual POP
   specific default parameters. When the real PPP authentication is
   engaged, the proxy will forwards the Access-Request to a RADIUS
   server, if this session was approved at pre-auth.  It can also
   process Access-Requests that were not preceded by a pre-auth
   exchange, and use the Username field for information about the



Mitton                       Informational                     [Page 11]

RFC 2882               Extended RADIUS Practices               July 2000


   desired realm, in it's policy evaluation.

   The other implementation performs a similar operations. It uses VSAs
   in the Access-Request to distinguish pre-authentication message
   types.

8.  Accounting Extensions

   Traditional Accounting only records session starts and stops which is
   pretty boring. Additional session information reporting can be added
   easily which gives a better picture of operation in use as they
   happen.  Some event types are listed below.

8.1.  Auditing/Activity

    - Call or Modem Starts, Stops
    - Tunnel Starts, Stops
    - Tunnel Link Starts & Stops
    - Admin changes

   These events if monitored by a stateful server can be used to gather
   information about the usage of the network on a user/session basis.
   Information about when a particular user entered the network is more
   relevant to network service management than attempting track
   backwards from low level IP address flows.   Useful information about
   port usage across a range of NASes allows service provider to quickly
   find problem areas or users.

   Information about call failures, successes, and quality are also
   deemed important many service providers.

   Extending RADIUS accounting is easy, it's surprising that more
   implementations have not been made in this area.

9.  Conclusions

   In real life RADIUS Servers are becoming rather complex software
   implementations.  They are often brokering authentication and
   authorization to other authorities or repositories.  Variants of
   RADIUS protocol is often used as glue protocol for these type of
   solutions.

   Some of the solutions are kludges that could be cleaned up by better
   underlying services.

   What this means to the implementor is that RADIUS as the RFCs
   describe it is becoming less relevant.  Many additional features
   require matching client and server processing message processing.



Mitton                       Informational                     [Page 12]

RFC 2882               Extended RADIUS Practices               July 2000


   Without standardization of these functions we don't have much
   interoperability in the field and much effort is spent in reverse
   engineering and reaction to unknown areas.

   This memo is not a complete survey by any means.  It is a
   representative summary of practices that I am aware of at the time of
   writing.  I still appreciate input from vendors or users on practices
   and details known, and particularly any reference material you can
   pass me.

10.  Security Considerations

   This document documents known practices, and does not propose any
   particular new protocols. Extensions to RADIUS protocols create new
   security implications because of their functions go beyond those
   considered in the RFCs.  Some of these include:

    - The ability to change passwords via a RADIUS exchange was
      deliberately left out of the protocol by the working group,
      because of security concerns.
    - The Pseudo-User profiles and the Call-Check operation may allow
      unintended access if static and well-know account names and
      passwords are allowed to be used by regular interactive accounts.
    - Resource Management operations must be protected from denial of
      service attacks.
    - Client side authorization change exchanges need to be secured from
      attacks that could disconnect or restrict user services.

11.  Implementation Documents

   Information about the following implementations can be obtained from
   the respective owners.  Most listed are available from the
   manufacturer's web site.

11.1.  Clients:

   - 3Com(USR) Total Control Hub
   - Ericsson(ACC) Tigris
           draft-ilgun-radius-accvsa-01.txt, Dec 1998
   - Lucent(Ascend) MAX TNT
   - Lucent(Livingston) Portmaster
   - Nortel(Aptis) CVX 1800
   - Nortel(Bay Networks) Versalar 5399/8000 Remote Access Controller
   - Intel(Shiva)







Mitton                       Informational                     [Page 13]

RFC 2882               Extended RADIUS Practices               July 2000


11.2.  Servers:

   - Ericsson(ACC) Virtual Port Server Manager
   - Funk Steel-Belted RADIUS
   - Intel(Shiva) Access Manager
   - Lucent(Ascend) Access Control
   - Lucent(Ascend) NavisAccess
   - Lucent(Ascend) Modified Livingston 1.16
   - Lucent(Livingston) V2.01
   - Lucent(Livingston) ABM
   - Lucent Port Authority
   - MERIT AAA Servers
   - Nortel(Bay Networks) BaySecure Access Control
   - Nortel Preside Radius
   - Nortel CVX Policy Manager

12.  References

   [1]  Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
        Authentication Dial In User Service (RADIUS)", RFC 2138, April
        1997.

   [2]  Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.

   [3]  Rigney, C., Willens, S., Ruebens, A. and W. Simpson, "Remote
        Authentication Dial In User Service (RADIUS)", RFC 2865, June
        2000.

   [4]  Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

   [5]  Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC
        2869, June 2000.

   [6]  Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and
        I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC
        2868, June 2000.

   [7]  Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting
        Modifications for Tunnel Protocol Support", RFC 2867, June 2000.

   [8]  Aboba, B. and G. Zorn, "Implementation of L2TP Compulsory
        Tunneling via RADIUS", RFC 2809, April 2000.

   [9]  Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC
        2548, March 1999.

   [10] Ilgun, K., "RADIUS Vendor Specific Attributes for ACC/Ericsson
        Datacom Access", Work in Progress.



Mitton                       Informational                     [Page 14]

RFC 2882               Extended RADIUS Practices               July 2000


13.  Author's Address

   David Mitton
   Nortel Networks
   880 Technology Park Drive
   Billerica, MA 01821

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










































Mitton                       Informational                     [Page 15]

RFC 2882               Extended RADIUS Practices               July 2000


14.  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Mitton                       Informational                     [Page 16]