[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freeradius-users
Subject:    Re: Questions on the finer points of CUI
From:       Stefan Winter <stefan.winter () restena ! lu>
Date:       2012-06-28 9:24:14
Message-ID: 4FEC22BE.4090807 () restena ! lu
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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" (application/pgp-signature)]

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[prev in list] [next in list] [prev in thread] [next in thread]