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
signature.asc
Description: OpenPGP digital signature
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html