Subject: [AAA-WG]: Session Termination Issues

From: Paul Funk <[email-masked]>
Date: Tue, 01 May 2001 19:58:47 -0400

I have several issues/questions relating to session 
termination.

Clarity of the draft
--------------------
I think that the draft (11.8) can give the impression 
that session termination has to do only with explicit 
termination at the request of the server (STI), and 
the STR/STA is merely a means of acknowledgement.

My understanding of the actual intent is that whenever 
a session terminates, the client is supposed to issue 
an STR to notify the server. The server is not meant 
to rely on accounting for such notifications. Thus, 
session termination serves two purposes -- to allow 
the client to notify the server of session state and 
to allow the server to explicitly terminate a session. 
If so, this should be made explicit.

Use of STR as indirect means of acknowledging STI
-------------------------------------------------
I think that the mechanism of issuing an STI to 
explicitly terminate a session and relying on STR/STA 
to acknowledge is problematic.

First, it is unnatural. Unlike a two-way transaction, 
there is no guarantee of a response. The server simply 
hopes to receive an STR. The STR is a SHOULD, not a 
MUST, so it may not be forthcoming. And what if the 
session is not active -- does the client lie and issue 
an STR anyway? If the server does not see an STR, 
should it retry the STI?

Second, what if the server that issues the STI is not 
the authenticating server? For example, you might 
want to maintain a server whose whole job is to kick 
people off the network. This forces the client to 
send an STR to the authenticating server, who is 
holding resources, as well as to the terminator 
server. This is outside the normal flow of processing.

Instead of an Indication, why not use Request/Answer 
to kill a session? There's no law that says requests 
can only flow downstream. That way, the terminator 
server gets the result of its request in a natural 
way, and the client simply issues the STR to the 
authenticating server as it would do anyway.

Sessions that don't start
-------------------------
A Diameter client may issue a request, get an accept 
and then decide not to start the session, for whatever 
reason.

The Diameter server will not know that the session was 
not started unless the client tells it. I think the 
draft should be explicit about this case, and specify 
that a client must issue a Session-Terminate-Request 
for sessions that are never started, as well as sessions 
that terminate normally.

In fact, it might be prudent to add a Termination-Cause 
AVP that indicates the reason for termination, e.g., 
user logoff, administrative, non-start, etc.

Sessions that time out
----------------------
The draft provides that a server must automatically 
release resources for a session that times out due to
Session-Timeout or Authorization-Lifetime. But is the 
client also required to issue a Session-Terminate-Request 
in this case?

Doing so may not be necessary, strictly speaking, but 
it might be advisable to require it in any case.

Paul

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 2 May 2001 13:49:19 -0700

> I have several issues/questions relating to session 

hmmmm... that is bad.

> If so, this should be made explicit.

yes, I will look over 11.8 again, and clean up the text.

> MUST, so it may not be forthcoming.

The text should state that an STR in response to an STI is a
MUST.

> And what if the 

It should return an MRI with the Result-Code set to 
the unknown session id error message.

> people off the network. 

I can see the possibilities of a start-up :)

> This forces the client to 

Not at all. If another server was to issue the STI, it would
receive the STR. It could process the STR, and proxy it to
the authenticating server.

> authenticating server as it would do anyway.

So only an STR and STA, and the STR can be initiated by
*any* peer? That still doesn't solve your "special purpose
Diameter server" problem, but I don't have a particular
problem with this approach. It would reduce the number of
messages, and presumably, complexity.

Others?

> Sessions that don't start

correct.

> user logoff, administrative, non-start, etc.

ok, but this is really extension specific, and some termination
causes don't apply to certain extensions.

> Sessions that time out

yes, but this is to protect against a client that has rebooted,
and will never issue an STR.

> it might be advisable to require it in any case.

Thanks,

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 3 May 2001 14:21:08 -0700

> yes, I will look over 11.8 again, and clean up the text.

Here is the text that I have come up with:

"The Diameter Base Protocol provides a set of messages that MUST be used
by any peer to explicitly request that a previously authenticated and/or
authorized session be terminated. Since the Session-Id is typically
tied to a particular service (i.e. Mobile IP, NASREQ, etc), the session
termination messages are used to request that the service tied to the
Session Id be terminated.

Session Termination MAY be initiated by a Diameter server, by issuing
a Session-Termination-Ind (STI) message to the access device. An access device
MUST issue a Session-Termination-Request (STR) message either upon receipt of
an STI, or when service to a particular user is terminated.

A Diameter server MUST be prepared to clean up resources if a session's
authorization lifetime has expired, and no STR was received. This event
could occur if an access device was to unexectedly reboot.

An access device MUST issue Session-Termination-Request messages for all
active session prior to an orderly reboot."

As far as eliminating the STI, in favor for allowing the STR to be initiated
by either the server or the client, I haven't received comments from the WG
in favor of this approach. 

PatC

---

From: "Fredrik Johansson" <[email-masked]>
Date: Fri, 4 May 2001 09:26:34 +0200

Hi

Comments below.

>in favor of this approach.

I believe that we can remove the STI, as far as I can see it does not add
any
extra value compared to sending an STR instead.

And it will be one message less to keep track of, which is good.

/Fredrik