Subject: [AAA-WG]: Issue #2: Proposal to modify STI

From: Pat Calhoun <[email-masked]>
Date: Tue, 15 May 2001 06:57:47 -0700

This is a recap of what I believe the issue that was reported by
Paul a few weeks ago, and my comments on how this could be achieved
given the new base protocol.

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

The base protocol has made the STR a MUST, unless an error occured
(see below).

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

A Failed-Ind will be issued by the NAS, with the Result-Code set to 
DIAMETER_UNKNOWN_SESSION_ID.

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

I do not believe there are any limitations in the protocol
that would restrict what you describe here.

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

A further e-mail stated that you were in fact proposing a new
set of messages (e.g. Kill-Session-Request/Answer). So
replacing the STI with two messages.

As it stands, I do not see any problems with the STI message,
*but* if it is decided that the resolution in Issue #1 (Routing
of Indication messages), requires that all indication messages
be responded to, then an STI would require two full round trips,
making the idea of a new message set (or re-using the STRs) MAY
make alot more sense.

Thanks,

PatC

---

From: "Martin Julien (ECE)" <[email-masked]>
Date: Wed, 16 May 2001 11:24:05 +0200

> The base protocol has made the STR a MUST, unless an error occured

Then, it seems that 3 messages (STI, STR/STA) are required for a 
task that could be handled using a single Request/Answer message
from an Authenticator server. I would prefer a simple Request/Answer
type of message from the Authenticator server which would inform
the Diameter client that it needs to release the resources for that
session. I do not really see what we gain by having a STI apart from
from the STR/STA message, in order to terminate a session on a client?

> that would restrict what you describe here.

From what I understand, I think the desired functionality here is 
a terminator server sending a "killing session request" message 
to the Diameter client, which would then send an STR to the Home
server with a reason that
a "Killing session request" has been received. If the Home server
accepts this, then it sends back a STA to the client, which in turn
responds to the killing session request with a successful answer.

I'm not sure what kind of terminator servers you have in mind,
but it would be nice to hear about it, since they also need
a session-Id I suppose?, unless it would be sufficient to only
request to kill all sessions based on User-Name, or something else
based on policies?