Subject: RE: (radius) Acct-Session-Id in Access-Requests

From: Ashwin Palekar <[email-masked]>
Date: Thu, 5 Nov 1998 18:28:11 -0800

Another possible approach is that the RADIUS server could generate a unique
Class attribute for each successful authentication and return it in the
access-accept. The NAS then sends the class attribute in each accounting
request for that session. This Class attribute can also be used to link
authentication_accepts with accounting records. Any disadvantages of using
the Class attribute instead of the NAS generating the Acct-Session-Id? 

-----Original Message-----
From: Carl Rigney [mailto:[email-masked]]
Sent: Wednesday, November 04, 1998 4:22 AM
To: [email-masked]
Subject: (radius) Acct-Session-Id in Access-Requests

Possibly I'm mellowing in my dotage, but as I'm looking over the
attribute tables for the revised drafts I recall that once upon a time
people asked about the possibility of allowing NASes to send
Acct-Session-Id in their Access-Request, so that such requests could be
linked up later with the matching accounting record.  At the time it
seemed marginal, but in the Brave New World of Proxy it seems more
useful.

Would there be a firestorm of protest if Acct-Session-Id were permitted
in Access-Request as well as Accounting-Requests?

--
Carl Rigney
RADIUS WG Editor
[email-masked]
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: MARC DE VRIES WE41/KT <[email-masked]>
Date: Fri, 06 Nov 1998 11:55:11 +0200 (MET-DST)

This has several drawbacks:

1. The Class attribute is already used for other purposes in some of the
implementations I have come across. Typically it is used to identify the
'group' the user belongs to. The wording in the RFC suggests such use. Other
implementations use it to get authentication-time info into the accounting
logs.

2. At least one NAS vendor I know of sends proprietary RADIUS messages (on
timer basis) with a list of how many sessions are currently active on the NAS
for each Class. Using a unique Class value per session would cause this message
to be too large (720 sessions per NAS). I read (I think it was on this mailing
list) other vendors provide per-Class information via SNMP.

With a formatted Class value (containing both a session-id and a user group id)
issue 1. could be solved, but not issue 2.

-