Subject: [AAA-WG]: [issue] Clarify relationship between auth and accounting sessions

From: Johan Johansson <[email-masked]>
Date: Tue, 30 Apr 2002 14:11:02 +0200

Submitter name: Johan Johansson
Submitter email address: [email-masked]
Date first submitted: 2002-April-30
Document: base (could also be that mip is the correct one)
Comment type: T
Priority: S
Section: 9.6
Rationale/Explanation of issue:

What is the relationship between session ids of authorizing sessions and 
accounting sessions, i.e. is there a difference between the authorizing 
session and the accounting one? There seems to be certain advantages to 
saying that they are separate sessions as I will describe below and I am 
not aware of any real benefit from saying that they are to be regarded 
as the same session. All relevant information is transported in each ACR 
and thus there seem to be little to be gained by correlating the 
accounting and authorization sessions based on the value of the 
Session-Id AVP.

Differences between implementations will inevitably lead to 
interopability problems.

The following scenario is from the mip application, but it boils down to 
whether accounting sessions have the same id as authorization sessions. 
The AAAH server may change for a variety of reasons, but the home agent 
(HA) must remain the same for the duration of the Mobile IP session. 
When a foreign agent (FA) sends an authorization request the AAAH 
initates a session involving the home agent. Since we have moved to a 
new AAAH the HA will receive a request for a session whose id is 
different from the one already active for the same user on the HA. 
According to the mip application the HA must replace it's existing 
session with the new one while retaining the same Acct-Multi-Session-Id. 
The follow-up question to this is what happens to the accounting. Do we 
send a new start record and start from scratch or do we continue with 
our existing accounting session? In many ways it would be more elegant 
and leave less room for errors to keep the existing accounting session, 
but this would require that it is in fact a separate session.

I am not sure whether this is properly a base or mip issue since section 
9.6. states

A Diameter application document MUST define the exact concept of a
   session that is being accounted

but the issue itself is quite fundamental.

Requested change:

   The Diameter protocol's Session-Id AVP, which is globally unique (see
   section 8.8), is used during the authorization phase to identify a
   particular session. Services that do not require any authorization
   still use the Session-Id AVP to identify sessions.

to

The Diameter protocol's Session-Id AVP, which is globally unique (see
section 8.8), is used during the authorization phase to identify a
particular session. Services that do not require any authorization
still use the Session-Id AVP to identify sessions. Accounting messages 
MUST use a different Session-Id from that sent in authorization messages.

j

---

From: <[email-masked]>
Date: Tue, 30 Apr 2002 15:16:53 +0300

Hi,

This change seems very reansonable to me.

br,
JPK

-----Original Message-----
From: ext Johan Johansson [mailto:[email-masked]]
Sent: 30. April 2002 15:11
To: [email-masked]
Subject: [AAA-WG]: [issue] Clarify relationship between auth and
accounting sessions

Requested change:

to

j

---

From: David Mitton <[email-masked]>
Date: Tue, 30 Apr 2002 17:51:51 -0400

On 4/30/2002 02:11 PM +0200, Johan Johansson wrote:
>not aware of any real benefit from saying that they are to be regarded as 
>the same session.

Sorry, I don't get it.  Why do I want to have to create two different 
identifiers for the same session?

>All relevant information is transported in each ACR and thus there seem to 
>be little to be gained by correlating the accounting and authorization 
>sessions based on the value of the Session-Id AVP.

less work?

>Differences between implementations will inevitably lead to interopability 
>problems.

that's for xxx sure!

>(HA) must remain the same for the duration of the Mobile IP session. When 
>a foreign agent (FA) sends an authorization request the AAAH initates a 
>session involving the home agent. Since we have moved to a new AAAH the HA 
>will receive a request for a session whose id is different from the one 
>already active for the same user on the HA. According to the mip 
>application the HA must replace it's existing session with the new one 
>while retaining the same Acct-Multi-Session-Id. The follow-up question to 
>this is what happens to the accounting. Do we send a new start record and 
>start from scratch or do we continue with our existing accounting session? 
>In many ways it would be more elegant and leave less room for errors to 
>keep the existing accounting session, but this would require that it is in 
>fact a separate session.
>

This smells like a MIP issue.
Most NAS applications wouldn't have this problem.

The problem is why is the session identifier changing?
Presumably, because some part of the session is moving/changing servers.
Either at the access end or the HA end.   This begs a philosophical 
question, what is the true session identifer?  Or more practically, what do 
we need to identify?

My gut says that the start of access from the MN to the network until 
hang-up is the "true session".  All handoffs and migrations are part of a 
MIP session continuity problem.  The MIP design should take this into 
account and provide the accounting with sufficent information to be able to 
track and charge appropriately.   This may entail a unique core session 
identifier, and sub identifiers for different configurations along the way.

Dave.