Re: CUI reloaded

[Tomasz Wolniewicz <twoln@xxxxxx>]

Hi all,
While implementing the plan described by Stefan, we have made some
observations which seem to be important for accounting in eduroam in
general.

It turns out  there is no real standard describing what attributes the
accounting packet should have.
Definitely, there is no requirement that it has the User-Name (which is
generally rather useless as this is only the outer value).
More importantly, there is no requirement that Calling-Station-Id is
present. I have looked at the data from all controllers that we have
tested so far and can confirm that they all contain Calling-Station-Id,
but I also have one example (3COM AP8760) which does NOT send this
attribute.
This observation has two implications.
First - in some cases it may be nearly impossible to bind an accounting
session to an authentication, hence to a particular user. This is
something worth keeping in mind, when one buys a piece of equipment.
There may be other ways of doing this binding (for instance the session
id may contain the Calling-Station-Id, but this very much depends on a
particular piece of hardware).
Second - sending accounting information back to IdP would make life even
more difficult for this IdP, since the IdP has no knowledge or control
over the hardware which is generating those accounting information. This
rather supports my view that accounting information SHOULD NOT be
proxied to the IdP. Having said that, I also realise, that this is a
wonderful case in favour of the CUI. The SP has the CUI from the
authentication, it knows its hardware and may build a custom method to
bind the authentication to accounting, hence it is capable of adding the
correct CUI to the accounting and make things meaningful for the idP :).
Third - the implementation of CUI in accounting can be done, as Stefan
has described, and is under preparation, but in some cases (hopefully
not too many) it may fail.

Cheers
Tomasz


stefan.winter@xxxxxxxxxx wrote:
> 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
>
>


-- 
Tomasz Wolniewicz    
          twoln@xxxxxx        http://www.home.umk.pl/~twoln

Uczelniane Centrum Informatyczne   Information&Communication Technology Centre
Uniwersytet Mikolaja Kopernika     Nicolaus Copernicus University,
pl. Rapackiego 1, Torun               pl. Rapackiego 1, Torun, Poland
tel: +48-56-611-2750     fax: +48-56-622-1850       tel kom.: +48-693-032-576