Taskforce Mobility Mailarchive
Hi,
Well no, I would prefer to tell them to turn off accounting, regardless
of the fact if they want to use CUI or not. What business do you have
as the IdP administrator to know how many bytes your roaming users are
transferring and at which places? These bytes do not belong to you,
they belong to the SP. The SP is not charging IdP for these bytes, so
this information should not be made available in the name of protecting
user's privacy.
Well, that's a valid argument for most of Europe, yes, but there are
other regions without "flatrate" outbound connectivity, for whom it
actually is important to know how much traffic their users generated.
This situation led in Australia to the VPN-only solution, so that
users will generate outbound traffic originating in their home
institution. AFAIK, in AU it is being looked into replacing this with
sending accounting information for backoffice cross-inst compensation.
So, I would feel very bad dismissing Accounting completely.
The SP has the right to gather this information, and
for this reason it would be very useful to be able to use CUI and
create usage statistics per CUI value.This will not be easy, if the
NASes do not handle CUI as they should. One way to implement this would
be to gather use statistics per guest IP and bind IP to CUI (as we
should anyway). This is not done via Radius accounting, but definitely
gives quite reliable information.
IETFs are great - I also had a chat with Alan DeKok about CUI and how
to satisfy the Accounting binding.
In the end, a rough plan emerged, and it doesn't even involve code changes :-)
* use a database for short-term storage of session information
* table schema: key(Client-IP-Address, Calling-Station-Id, User-Name)
-> CUI, Creation-Date[auto-update]
* instantiate a sql module with queries that add/modify/delete rows in
this table
- in authorize_query: when adding the NUL CUI request into the
request, create a new row filling (Client-IP-Address,
Calling-Station-Id, User-Name) - leaving the CUI field empty
- in postauth_query: when server sends back CUI, update table with CUI
- in accounting_start, update: lookup CUI, if exists, add to packet
- in accounting_stop: delete row
The table will accumulate rows of users who tried to authenticate, but
failed - it is safe to delete such stale entries after a very short
time then (by comparing creation-date), this can happen off-FreeRADIUS.
This sql module could be conveniently named "cui" and maybe shipped by
default in FR - then all an administrator who wanted it would have to
do is: uncomment a
# cui
line in authorize, post-auth, accounting
It might be cool to have more refined queries that help one to
implement policy: if a row was created during request, but in
post-auth there was no CUI delivered, that could optionally turn the
accept into a reject - if that is your local policy (which I
understand it is NOT though, right?).
Also it would be cool to forge a query in accounting-stop that both
adds CUI *and* deletes the row afterwards.
Greetings,
Stefan Winter