[VOPRadius] Radius Redirection & need for Radius COA messages

[Sylvain Savignac]

Title: Message

Hello Nick   The latter is an extract from current draft: http://www.ietf.org/internet-drafts/draft-lior-radius-redirection-01.txt   The latter is based on Informational RFC: http://www.ietf.org/rfc/rfc3576.txt   RFC3576, which is not a standard track, defines COA messages: " The RADIUS protocol, defined in [RFC2865], does not support unsolicited messages sent from the RADIUS server to the Network Access Server (NAS).   However, there are many instances in which it is desirable for changes to be made to session characteristics, without requiring the NAS to initiate the exchange. For example, it may be desirable for administrators to be able to terminate a user session in progress. Alternatively, if the user changes authorization level, this may require that authorization attributes be added/deleted from a user session.   To overcome these limitations, several vendors have implemented additional RADIUS commands in order to be able to support unsolicited messages sent from the RADIUS server to the NAS. These extended commands provide support for Disconnect and Change-of-Authorization (CoA) messages. Disconnect messages cause a user session to be terminated immediately, whereas CoA messages modify session authorization attributes such as data filters. "   VOP Radius does not support COA messages. RFC3576 is not a standard track and Vircom did not get any request before this one to have VOP Radius support for COA messages in a near future. At this point in time, it would be considered as customisation of VOP Radius.     Sylvain Savignac, P. Eng.   Development Lead RADIUS Development Unit Vircom Inc.     -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Crocker Sent: October 11, 2004 3:11 PM To: [EMAIL PROTECTED] Subject: [VOPRadius] Radius Redirection Are there any future plan to implement this in vopradius?     1.  Introduction      From time to time an Internet Service Provider (ISP) requires to    restrict a user's access to the Internet and redirect their traffic    to an alternate location.  For example, the user maybe on a prepaid    plan and all the resources have been used up.  In this case the ISP    would block the user's access to the Internet and redirect them to a    portal where the user can replenish their account.  Another example    where the ISP would want to restrict access and redirect a user that    was involved in some fraudulent behavior.  Again the ISP would want    to block the user's access to the Internet and redirect to a portal    where they can inform the user as to their state and allow them to    inform the user of their concerns and potentially rectify the    situation.      In the examples above it is important to note that the ability to    block and redirect user's traffic is required at service initiation    and once service has been established.  These capabilities must also    be available across access technologies and various business    scenarios.  For example, the ability to block and redirect traffic is    required for TCP users, cell phone users, WiFi users.  As well, this    capability must work whether the user is in their home network or    roaming in a visited network which may or may not have a direct    roaming relationship with the user's home network.      This document describes a protocol extension to the Remote    Authentication Dial In User Service (RADIUS) Protocol RFC2865 [3] by    which the aforementioned requirements can be addressed.  To meet    these needs five new RADIUS attributes are required.      One option for providing these capabilities is to utilize RADIUS    attributes for tunneling protocol specified in RFC2868 [5].  This    document describes how to provide capabilities for users traffic    redirection with or without using tunnels.  Finally, the document    describes how to provide for these capabilities dynamically    (mid-service) using the RADIUS procotol extension described in    RFC3576 [8].      Blocking and redirection of users traffic is known as hot-lining of    accounts.  In this document, hot-lining is used as the motivation for    these attributes and an illustration of how they would be used.    However, the NAS-Filter-Rule(TBD), IP-Redirection-Id(TBD),    IP-Redirection-Rule(TBD), HTTP-Redirection-Rule(TBD) and    HTTP-Redirection-Id(TBD) may be used together or separately to    provide other features.   Thanks,     Nick Crocker Network Administrator Tri-lakes Internet, Inc. 517 S. Second St. Branson, MO. 65616 [EMAIL PROTECTED] http://www.tri-lakes.net tel: fax: 417-335-7889 417-339-9158   Add me to your address book... Want a signature like this?

<<image001.jpg>>