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

From: Pat Calhoun <[email-masked]>
Date: Tue, 19 Jun 2001 11:05:30 -0700

All,

I have some comments on this issue.

> - 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.

> - Change name of Authorization-Lifetime to Reauthorization-Timeout 

I'm not particularly fond of this one.

> - 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.
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.

> - 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.

PatC

---

From: Jacques Caron <[email-masked]>
Date: Tue, 19 Jun 2001 23:49:01 +0200

>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).

>I'm not particularly fond of this one.

Depends on the exact semantics of the AVP as detailed above.

>    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?

>    but once session-timeout expires (from the beginning of the session),

Don't quite see the difference (other than you don't mention Auth-Lifetime)?

>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.

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

Jacques.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com