CUI reloaded

[stefan.winter@xxxxxxxxxx]

Hello all,

being at the IETF this week, I got to have a chat with Jouni Korhonen,  
co-author of the "Chargeable User Identity" RFC4372.

If you've been following the work Tomasz has been doing regarding CUI,  
you'll probably recall that implementations on the NAS side isn't  
really great. Tomasz proposed a method to enable FreeRADIUS to inject  
CUI requests in the server side.

I didn't really like the idea so far, because the RFC speaks of the  
NAS requesting CUI, not an intermediate proxy.

Now in my chat with Jouni, it turned out that most other roaming  
environments (telco market) don't trust their NASes anyway, and always  
treat CUI within the first AAA server in line - just like Tomasz  
proposed for FreeRADIUS requesting it at the SP side.

The only thing to consider is the MUST regarding Accounting packets:  
When a CUI for a user has been negotiated, the Accounting packets MUST  
include the CUI.

Unfortunately, if done at the server side, this requires the AAA  
server to maintain state for his session, which is not usually the  
case right now:

"If the CUI was included in an Access-Accept packet, RADIUS clients
   supporting the CUI attribute MUST ensure that the CUI attribute
   appears in the RADIUS Accounting-Request (Start, Interim, and Stop).
   This requirement applies regardless of whether the RADIUS client
   requested the CUI attribute."

With the SP server taking the role of the requesting client, it must  
also take the responsibility for adding the attribute to accounting  
messages for that user.

I haven't thought yet about how that would be done in FreeRADIUS (or  
Radiator, for that matter). If anyone has some suggestions, I'd be  
more than happy to hear them.

Greetings,

Stefan Winter