Subject: [AAA-WG]: Session issues on 04-alpha1

From: "Yolanda Garcia-Serrano (ECE)" <[email-masked]>
Date: Fri, 11 May 2001 11:05:21 +0200

Hi again, Pat

I open a new thread on some session details in 04-alpha1: 

 Authorization Sessions
------------------------------------------------------------------------------------
I missed another state in the Authorization State Machine:
     Open      Authorization-Lifetime expires on      ?      Closed
                    home AAA-server

The action to be done when Authorization-Lifetime expires depends on a needed IMHO
 clarifying text on the following paragraphs:

10.0
   ...
   Authorization-Lifetime AVP defines the maximum amount of time a user
   MAY make use of the resources before another authorization request is
   to be transmitted to the server. If the server does not receive
   another authorization request before the timeout occurs, it SHOULD
   release any state information related to the user's session. 

10.9
   ...
   A Diameter server MUST be prepared to clean up resources if a
   session's authorization lifetime has expired, and no STR was
   received. 

What does 'prepared to clean up resources' exactly mean? When Authorization-Lifetime
expires on the server, what action has to be taken by the server?
It could send a a Challenge (ACI / DEI) to force the re-authorization, or send a STI 
(in the same way as it is done when Session-Timeout expires). In the last case (send 
a STI), there would be no difference between Authrorization-Lifetime and Session-Time,
which seems not very good if needed such difference.

Maybe it would also help to specify in the text that Authorization-Lifetime MUST be 
always smaller than Session-Timeout.

As well, is [Session-Timeout] missing in ABNF and AVP table for AAA, DEA, AMA, ACA messages? 
This would give the possibility to inform the Diameter client about the number of 
seconds the home AAA server is going to wait before issuing an STI.

Accounting Sessions
----------------------------------------------------------------------------------
As an accounting session can exists without any related authorization on, in 
Accounting Session State Machine, I miss following states:

      Open      Receive accounting interim     send       Open
                record                         accounting
                                               interim
                                               answer

      Open      Session-Timeout Expires on     send STR   Discon
                Access Device

      Open      STI Received                   send STR   Discon

      Open      Session-Timeout Expires on     send STI   Discon
                home AAA server

      Discon    STR Received                   Send STA   Closed

      Discon    STA Received                   Discon.    Closed
                                               user/device

Session Movement
-----------------------------------------------------------------------------------
   In order to support these applications, when an
   AAA server identifies that a request is the continuation of an
   existing session, ...
I'm wondering how could *any* server detect than an incoming request containing in 
principle a new Session-Id is a continuation of a previosly existing one? I guess
we DO NOT ONLY allow a session per user...

Thanks,
Best regards
	/Yolanda García

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 11 May 2001 10:41:08 -0700

>  Authorization Sessions

Actually, I changed:

to:

      Open      Session-Timeout or             send STI   Discon
                Authorization-Lifetime 
                expires on home AAA server

> What does 'prepared to clean up resources' exactly mean? 

quite vague, and changed to:

"A Diameter server MUST clean up resources (e.g. session state) if a
session's authorization lifetime has expired, and no STR was received.
This event could occur if an access device was to unexpectedly reboot."

> When Authorization-Lifetime

It should send an STI (see the above new state table entry).

> which seems not very good if needed such difference.

The main difference, which apparently needs clarification, is that the
Session-Timeout is returned from the server when it will not "re-authorize"
a session. Once the Session-Timeout has expired, the user is disconnected.
When the Authorization-Lifetime has expired, the access device MAY
request re-authorization.

For instance, a RADIUS home server would never return an
Authorization-Lifetime AVP, since RADIUS doesn't have the concept of
re-authorization, so it would only include the Session-Timeout.

hence:

and:

      Open      Authorization-Lifetime about   send       Open
                to expire on access device     service
                                               specific
                                               auth req

The Authorization-Lifetime text already stated that a re-auth was
required after expiration, but the Session-Timeout text was a tad vague.
I have changed it to:

10.5  Session-Timeout AVP

   The Session-Timeout AVP (AVP Code 27) [1] is of type Unsigned32 and
   contains the maximum number of seconds of service to be provided 
   to the user before termination of the session. A session terminated
   due to the Session-Timeout expiration MUST NOT generate a
   re-authentication and/or re-authorization.

   A value of zero, or the absence of this AVP, means that this session
   has an unlimited number of seconds before termination.

   [...]

> always smaller than Session-Timeout.

or the same, if the access device doesn't support re-auth.

10.4  Authorization-Lifetime AVP

   [...]
   If both this AVP and the Session-Timeout AVP are present in a message,
   the value of the latter MUST NOT be smaller than the Authorization-Lifetime
   AVP.

> seconds the home AAA server is going to wait before issuing an STI.

cool, thanks.

> Accounting Sessions

This one is already covered, right?

>       Discon    STA Received                   Discon.    Closed

no you seem to have missed the point of the state machine. If accounting
ONLY is done, a Stop accounting record is the only termination you
need. ST* messages are only used when auth is performed.

So, if you have two separate servers handling both auth and acct, one
will get the auth and STR message for cleanup, while the other will
receive the acct start and the stop for cleanup. Requiring an STR
would mean tha the access device would have to know that two 
separate servers were used, and would have to issue two STRs.

See the problem?

> Session Movement

Actually, this was added to the base in -03 to try to fix some issues with
the Mobile IP extension, but due to our recent conference call, we came
to the conclusion that this AVP is no longer necessary. So the actual -04
will no longer include the Session Movement section and sub-sections.

Thanks,

PatC