[VOPRadius] Radius Redirection & need for Radius COA messages

[Larry Essary]

 
 
VOP Radius does not support COA messages. RFC3576 is not a standard
track and Vircom did not get any request before this one

I asked for it months ago and was told it was not supported.   Who is responsible
for keeping customer requests of this nature ?

Larry Essary

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,