Questions on the finer points of CUI

[Stefan Winter]

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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20120628/67bdc926/attachment.pgp>