[c-nsp] Discussion list for RADIUS?

[Tuc at T-B-O-H.NET]

Hi Justin,

	Thanks, thats pretty much what I understood. I was hoping that
maybe while I was sending "Accounting-Request" packets with interim updates
to time and input/output octets, that I was reading the "Accounting-Reply" 
wrong and potentially could get some sort of a notification that the
time had expired, user is no longer valid, etc.

	I was hoping that the device wouldn't have to be the one to
keep track of it, that it could be oblivious and all of a sudden get
a reply of "Thanks for the update, but you should know the user is
(deleted, out of time, over his octets, crazy {Thats the "AR2TUC"
reply. ;) })

	Okay, I guess I have to store the data and just before I
update accounting check to see if the user is "over the limits".
(Unless anyone contridicts what you say, but its what I understood
too)

		Thanks, Tuc

> 
> As far as I am aware (from years of working at ISP's), neither will a  
> RADIUS server send nor most NAS devices ever check the status of any  
> attribute post login (I don't even think they can, but it's been a  
> long time since I've read the RFC's). Meaning, if you change the  
> session timeout, it wont apply to any active sessions. The most that  
> ever happens after authentication is radius accounting messages, which  
> the NAS may send when a users session ends, or really whenever it  
> wants (e.g. if it's resetting counters because they've exceeded the  
> maximum storage size of the radius accounting attribute, or on some  
> devices when you reset the interface counters it sends an accounting  
> message with the old counter statistics before doing so).
> 
> The only way to guarantee the policy change is made is to disconnect  
> the user and force them to re-authenticate. In our case, we had this  
> issue come up when DSL users changed bandwidth plans, and we had to  
> disconnect them after making a change to that attribute.
> 
> Justin
> 
> On May 23, 2008, at 9:47 PM, Tuc at T-B-O-H.NET wrote:
> 
> > Hi,
> >
> > 	What it boils down to is that when you auth, you have the potential
> > for a "Session-Timeout" reply. Lets say its 120 minutes. You get  
> > back that
> > you are authorized with that attribute.
> >
> > 	You send the accounting start record and off the user goes. 10  
> > minutes
> > into the session, the operators/a process/whatever decides to change  
> > your Radius
> > entry so that the new Session-Timeout would be 5 minutes. How, if at  
> > all, does
> > the NAS become aware of this?
> >
> > 	It doesn't seem that accounting records play into any of this. I
> > see where in 2866 you send a type 4, and get a type 5 back  
> > (Accounting-Request
> > and Accounting-Response). The Accounting-Response seems like it only  
> > says
> > "I've seen, I've recorded, thank you". If the ID was deleted, it  
> > appears it
> > might not care.
> >
> > 	I'm just wondering except for constantly re-authorizing and getting
> > the Session-Timeout (Or worse, an Access-Reject) is there any way  
> > for a NAS
> > to know that the Session-Timeout has expired, the ID is no longer  
> > valid, etc.
> >
> > 			Thanks, Tuc
> >>
> >> Why don't you just ask your question, and if anyone can help you or  
> >> point
> >> you in the right direction we will?  I know you said it is not a  
> >> Cisco
> >> product question, but there have been enough emails already that  
> >> initially
> >> asking the question, but asking for direct replies instead of to  
> >> the list
> >> because it wasn't a Cisco question, would probably have been more  
> >> efficient.
> >>
> >> Thanks,
> >>
> >> Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS
> >> Senior Network Engineer
> >> Coleman Technologies, Inc.
> >> 954-298-1697
>