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='0000-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 - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473