Subject: RE: [AAA-WG]: Issue 82: Reauthorization Issues

From: "Martin Julien (ECE)" <[email-masked]>
Date: Thu, 28 Jun 2001 11:35:00 +0200

See comments.

> > > - In 10.7 (and elsewhere) clarify Authorization-Lifetime 
> (means Reauth
> > > should be performed) and Session-Timeout. Resources 
> should be liberated
> > > upon Session-Timeout only, not upon 
> Authorization-Lifetime expiration.
> >
> >but it is valid for an answer message to only include the 
> >Authorization-Lifetime,
> >and not the Session-Timeout.
> 
> The problem is that if Authorization-Lifetime is a trigger 
> for a reauth 
> request, then there should be some time between the start of 
> the reauth and 
> really freeing all associated resources. But there should be 
> an absolute 
> maximum to the session duration.
> 
> I would say that if there is an Authorization-Lifetime, there 
> should be a 
> Session-Timeout too, with a value slightly higher. In other words, 
> Authorization-Lifetime just means "ask for a reauth after n 
> seconds". If 
> that doesn't happen, then the session is dropped because of 
> Session-Timeout, not because of Authorization-Lifetime 
> (otherwise there is 
> a duplicate in semantics).

A Diameter client must send a re-auth message at the Authorization-Lifetime
expiration, and free all resources if it can not get a re-auth answer before
the Session Time-out expiration. Is it what the Session Time-out AVP is 
supposed to be used for in the answer?, or is it left to the client itself
to take the proper action when it can not get a re-auth answer?

A Diameter Home server, informs the client of the Authorization-Lifetime,
which means that the client should re-auth before the expiration of the
Authorization-Lifetime, right? Should it send the re-auth at the expiration
of the Authorization-Lifetime?, or slightly before? MUST the AAAH release
resources or not, when the Authorization-Lifetime has expired? What seems to
make sense to me, is that the client should send the re-auth message at the 
Authorization-Lifetime, while the AAAH server expects a re-auth to be received
from the client before the Session-Time-out expires. That would mean that 
the AAAH would only free resources once the Session-Time-out has expired in
the AAAH server. The Session-Timeout should be reset after the re-auth 
request is re-authorized by the server.

I don't really see the point of having a Session-timeout that disconnect
a client independently of authorization.

A problem we are having right now with the actual specification, is that
if a AAA Home release a session based on the Authorization-Lifetime 
expiration, because the client is late sending the re-auth, what
should the AAA Home do when it receives it? Since there is no difference 
in the AA-Request for initial authentication+Authorization, then I guess
the AAA Home would authenticate+Authorize and return a new IP address and
authorization AVPs, right? That is a problem. So, if we release the session
only after the Session-Timeout, it reduces the risk of receiving a late
re-auth message, but it still remains. Should we have an additionnal 
information in the AA-Request informing the AAA Home that the client is
asking either for an initial auth, or a re-auth?

> > > - Change name of Authorization-Lifetime to Reauthorization-Timeout
> >
> >I'm not particularly fond of this one.
> 
> Depends on the exact semantics of the AVP as detailed above.

I agree.

> > > - Authorization-Lifetime and Session-Timeout based from start of 
> > Session or
> > > from receipt of message (in reauth)?
> >
> >ok, this should be clarified. Of course, I wonder what the 
> right answer is.
> >a couple of options:
> >
> >1. a re-auth is expected after Authorization-Lifetime, and 
> if no answer
> >    is received by Session-Timeout, resources are cleaned up.
> 
> That's what I think, but the issue is:
> - upon reauth, there should be a new Authorization-Lifetime & 
> Session-Timeout.
> - from when are these counted? The original authorization, or 
> the new one?
> 
> >2. Session-Timeout is the end of the session. The user is 
> free to re-auth,
> >    but once session-timeout expires (from the beginning of 
> the session),
> >    it's game over.
> 
> Don't quite see the difference (other than you don't mention 
> Auth-Lifetime)?
> 
> > > - In reauth, is it allowed to change authorization 
> parameters (filters,
> > > IPs...)?
> >
> >good question. perhaps some text stating that 
> non-conflicting authorization
> >information MAY be returned in re-auth messages.
> 
> How do you define "non-conflicting"? A few "hints" on that...
> - it is quite useful to be able to change filters on the fly 
> (e.g. a user 
> starts with restricted filters, then something external makes 
> us open the 
> filters. Or the opposite, a user starts with full access, but 
> then upon 
> reauth we find out that he's out of credits, but we still 
> want him/her to 
> have access to a specific www site to buy some more, so we just close 
> filters instead of just disconnecting the user)
> - some things like IP addresses are quite harder to change on 
> the fly, at 
> least in an PPP context.

Good question! Should the AAA make a distinction between authorization
and re-authorization?

> [which raises an interesting point, does Diameter have 
> everything needed to 
> centralize DHCP authorization?]

What do you mean? Should the client connects directly to DHCP?, or
should the AAA returns an equivalent DHCP information to the client?
I think that Mobile-IP WG went through the same discussion.

> Jacques.