RE: Chargeable-User-Identity

["Dave Nelson" <d.b.nelson@comcast.net>]

Stefan Winter writes...

Let me try to understand you usage a little better.

> Our motivation is not billing, but being able to recognize
> fraudulent users when they return...

By "fraudulent", do you mean a user that is unknown or invalid at the home
AAA server?  Or do you have some other thought in mind?

> ... to have a means of permanently banning them.

Well, if the home AAA server continually sends Access-Reject, the user would
be permanently banned.  No?

So, I'm thinking you likely have another idea in mind, such as protecting
from DoS attacks or use of resources in the roaming partner's network by
unauthorized users.  A pre-authentication sort of behavior, like Call-Check
used to provide in dial-up networks.

> .. E.g. a user could change his MAC and outer identity on every
> re-connect, and evade blocking measures ...

Blocking where, exactly? 

> ...if no permanent opaque handle identifies him on return.

Well, keep in mind that CUI was designed to be an opaque cookie of meaning
only to it's issuer, the home AAA server.  Edge devices, e.g. NASes could do
a binary comparison for equality to tell that one CUI is the same as
another. That much is feasible.  Are you suggesting that NASes keep a
"denied parties list" or "blacklist" of CUIs?

> ...since there is no reliable end-to-end identifier for
> service providers...

Nor has there event been one in RADIUS.

> ... the home server may not know which business partner
> it is talking to - it sees only the proxy's connection.

Well, it is in fact only "talking' to the immediate proxy.  It has to rely
on the chain of proxies to "do the right thing" on its behalf.  That's also
a central tenet of the RADIUS architecture, limiting as that my be in
certain circumstances.  You simply have to trust the proxies.

> A concrete example from the RFC is: "For example, the lifetime can be
> set to one billing period." A home server H doing business with two
> service providers S1 (billing period: end of month), S2 (billing period:
> 25th of every odd month) via a proxy P would need to see an identifier
> for S1, S2 when receiving Access-Requests from P to adjust the CUIs it
> generates properly, and roll them over at the appropriate end of billing
> period.

That assumes the home server tries to optimize its data storage and internal
state by the clever the "re-use" of CUIs.  The [unstated] idea behind CUI
was that it would be converted back to the true user identity when received
at the home RADIUS accounting server, as a trusted extension of the home
RADIUS server, it is entitled to know how to decode the CUI contents.

Are you saying that the home provider expects to get a detailed bill from
each remote partner that includes connect minutes associated with each
corresponding CUI and will attempt to reconcile that bill for potential
fraud?



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>