On 28.06.2012 09:07, Scott Armitage wrote:
All,
I was after some clarification about the implementation of CUI in freeRADIUS.
My first point is the use of Client IP Address. I notice that client IP
Address makes a regular appearance but I'm wondering whether it should.
Looking at the cui.conf the post-auth insert adds the Client IP Address.
postauth_query = INSERT IGNORE INTO ${cui_table} \
(clientipaddress, callingstationid, username, cui, lastaccounting) \
VALUES \
('%{Client-IP-Address}', '%{Calling-Station-Id}', '%{User-Name}',
'%{reply:Chargeable-User-Identity}', NULL) ON DUPLICATE KEY UPDATE
lastaccounting='-00-00 00:00:00',
cui='%{reply:Chargeable-User-Identity}';
likewise the schema (in cui.sql) even has the Client IP Address as a primary
key which to me seems wrong. In the world of eduroam my RADIUS server can
proxy off to one of 3 National Proxies each will have a different Client IP
Address, therefore a single client could have 3 entries in the cui table
depending upon which National proxy dealt with the request. I don't see the
point of the Client IP Address being in there. If each home server is using
a salt (together with the operator name) then even the same username and
calling station id will return a different CUI for different home servers.
Maybe some could explain what I'm missing and why the Client IP Address is
there?
The $cui_table is merely a helper table to bind returned
CUI values from the home server during the *authentication* phase to a
possible subsequent Accounting packet for that same session. It is
logically maintained at the SP side of the transactions (i.e. towards
Access Points and Controllers).
When doing auth, Calling-Station-Id and a User-Name are present in the
request. The response contains the associated Chargeable-User-Identity,
and may or may not contain a User-Name, and that User-Name may or may
not be the same as the request had.
If the NAS doesn't bin auth-CUI to acct-CUI itself (which is true for
most NASes), the SP-side RADIUS server needs to do guesswork to add the
CUI attribute to the outgoing accounting request (for all such requests:
starts, interims and stops).
It can see the binding primarily by observing that the calling-station
ID is the same.
It can not use the User-Name in Accounting because some NASes use the
value of an Access-Accept instead of the original value.
In principle, one could stop here. However, if a user moves from one NAS
to another, he needs to reauthenticate and has the same
Calling-Station-Id. This new authentication might get the same CUI or
another (as you rightly note, the next request can go to a different
home server, who might calculate his own CUI).
In that case, there are two entries for the same Calling-Station-Id with
different CUIs, and the server won't know which one to attach to the
next outgoing Accounting-Request - BAD.
That's why the Client-IP-Address is a secondary key: since we're talking
SP-side, the client is the Access-Point or Controller, and the tuple of
(CSI;Client-IP) makes the CUI value unique: This device *on this client*
at a particular point in time.
You might argue that the user could close the session and then re-auth
on the *same* NAS. That's true, but it is not a problem: if that
previous session was closed in order with an Accounting-Stop, the
temporary entry in $cui_table gets deleted, and the new session gets the
new one. If not, since the key of CSI and Client-IP is identical, the
new session overwrites the CUI value of the previous one.
This should also explain your subsequent queries below.
Greetings,
Stefan Winter
Staying with the Client IP Address, my next point surrounds the Accounting.
The cui.conf shows that accounting updates the table using Client IP Address
in the search:
accounting_start_query = UPDATE ${cui_table} \
SET \
lastaccounting = CURRENT_TIMESTAMP \
WHERE clientipaddress = '%{Client-IP-Address}' \
AND callingstationid = '%{Calling-Station-Id}' \
AND username = '%{User-Name}' \
AND cui = '%{Chargeable-User-Identity}';
How would this work? The NAS doesn't know what the Client IP Address is and
doesn't send it in Accounting packets.
Finally, why does the Accounting stop for cui remove the cui from the
database:
accounting_stop_query = DELETE FROM ${cui_table} WHERE \
clientipaddress = '%{Client-IP-Address}' \
AND callingstationid = '%{Calling-Station-Id}' \
AND username = '%{User-Name}' \
AND cui = '%{Chargeable-User-Identity}';
Surely I'd want to keep this? If 2 weeks later I get a copyright
infringement notice for a client, I'd want the CUI when contacting the home
site of the user.
Thanks
Scott Armitage
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
--
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA
