RE: Chargeable-User-Identity

[<Pasi.Eronen@nokia.com>]

Hi,

RFC 5580 does specify an "Operator-Name" attribute (to identify the
access network operator/"NAS owner") -- would it be useful in your
situation?

Best regards,
Pasi

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org [mailto:owner-
> radiusext@ops.ietf.org] On Behalf Of ext Stefan Winter
> Sent: 10 August, 2009 09:32
> To: radiusext@ops.ietf.org
> Subject: Chargeable-User-Identity
> 
> Hello,
> 
> in eduroam, we are just about starting to make real use of the
> Chargeable-User-Identity (RFC4372). Our motivation is not billing, but
> being able to recognise fraudulent users when they return, to have a
> means of permanently banning them. E.g. a user could change his MAC and
> outer identity on every re-connect, and evade blocking measures if no
> permanent opaque handle identifies him on return.
> 
> We are mostly happy with the RFC, but one of my colleagues stumbled
> upon
> something. The RFC says that the business agreement between service
> provider and home server determines the lifetime of a CUI. While that's
> correct, there is a problem when intermediate proxies are involved
> (like
> a clearing-house): since there is no reliable end-to-end identifier for
> service providers, the home server may not know which business partner
> it is talking to - it sees only the proxy's connection.
> 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.
> 
> There is not currently a standard attribute to convey this information.
> NAS-IP-Address and NAS-Identifier are semantically bound to a single
> NAS. A service provider can operate multiple NASes, on the same or
> different access media.
> 
> I'm not sure if there is much to do about this. I suppose a good
> real-life way to do this is to set a VSA with the information, and make
> sure that P sets it for its customers. I wonder if it's worth defining
> a
> properly standardised attribute for this though (since implementing
> RFC4372 seems to implicitly require its existence)...
> 
> Greetings,
> 
> Stefan Winter
> 
> --
> 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
> 
> 
> --
> 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/>

--
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/>