Subject: Re: [AAA-WG]: NASREQ14: Problem with Acct-Session-Id and Session-Id

From: David Mitton <[email-masked]>
Date: Thu, 04 Mar 2004 11:46:40 -0500

On 2/20/2004 02:14 PM -0500, Avi Lior wrote:
>Problem with Acct-Session-Id and Session-Id
>
>Submitter name: Avi Lior
>Submitter email address: [email-masked]
>Date first submitted: February 20th 2004
>Reference:
>Document: NASREQ-14
>Comment type: Technical
>Priority: S
>Section: 9.2
>Rationale/Explanation of issue:
>
>When the corresponding response is received by the Translation Agent, it
>says that
>Acct-Session-Id attribute is to be placed in Session-Id.
>
>The problem is that Acct-Session-Id will always change when there are
>multiple session in RADIUS.

Huh??  If there are multiple sessions, then there has to be multiple Ids.
My RADIUS sessions do not change Acct-Session-Id in mid-session.  That 
doesn't make sense.

>In diameter Session-Id remains constant and therefore placing it in
>Session-Id will violate Diameter.

Yes, but there is a another issue here too.

>What really needs to happen is much more complex.
>
>Requested changes:
>
>Acct-Session-Id attribute should be placed in Accounting-Sub-Session-Id AVP.

I think that works.  But we're going in the wrong direction in Section 9.2 
here.
This section is primarily generating a RADIUS message from Diameter.
It does need to translate the response, but the session identified 
information would be retained from transaction state cache.

>The Translation Agent should be the one generating a Session-Id for the
>session and its sub-sessions.
>
>It will place Session-Id in the diameter messages.

Right, the bigger issue for the Diameter/RADIUS gateway is that Diameter 
has a unique Session-Id, that spans authentication and accounting, but 
RADIUS does not.

Section 9.2 talks about Diameter to RADIUS translation.
RADIUS doesn't have Session-Id attribute, only the Acct-Session-Id.

So we can either drop Session-Id, substitute it for another attribute, or 
prepend/append it to something.  As long as it's consistent and the RADIUS 
server is happy with the results.  A possible algorithm would be prepending 
it to Accounting-Sub-Session-Id (which may not be present).  That way 
preserving information, order and uniqueness.

When doing the reverse translation (section 9.1) things get more interesting.

I have taken the position that a RADIUS to Diameter gateway will have to 
synthesize unique Diameter Session-Ids for any RADIUS-side generated 
Access-Requests (or COAs and Disc-Reqs).  And this would become part of the 
session state it would have to track for all messages that relate to that 
session, as long as it's active.

Any discussion?

Dave.

---

From: "Fox, Dan" <[email-masked]>
Date: Thu, 4 Mar 2004 16:52:59 -0500

Dave,

Comments below.
 
-Dan Fox
Starent Networks

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of David Mitton
Sent: Thursday, March 04, 2004 11:47 AM
To: Avi Lior; [email-masked]
Subject: Re: [AAA-WG]: NASREQ14: Problem with Acct-Session-Id and Session-Id

Huh??  If there are multiple sessions, then there has to be multiple Ids.
My RADIUS sessions do not change Acct-Session-Id in mid-session.  That
doesn't make sense.
[Fox, Dan] CDMA billing has a correlation id that matches all of the accounting messages for a session, and each RADIUS START/STOP pair has a different Acct-Session-ID.  I *think* that's what Avi is referring to. 

Right, the bigger issue for the Diameter/RADIUS gateway is that Diameter
has a unique Session-Id, that spans authentication and accounting, but
RADIUS does not.
[Fox, Dan] CDMA billing has a 3GPP2-Correlation-ID which serves this purpose, but this attribute is domain-specific to CDMA.  At Starent, we, however, use the same attribute (same Vendor ID and VSA type number) for correlating HA accounting as well.  Yes, we have customers that require this for HA as well.  We also put this ID into authentication messages for the same session.  Would it be appropriate here to define a new attribute for RADIUS that does this? 

Any discussion?

Dave.