RE: Chargeable-User-Identity

[<lionel.morand@orange-ftgroup.com>]

Hi Stephan,

It should be! The Operator-Name attribute was defined for that :)

Best Regards,

Lionel

> -----Message d'origine-----
> De : owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] De la part de 
> Pasi.Eronen@nokia.com
> Envoyé : lundi 10 août 2009 08:42
> À : stefan.winter@restena.lu; radiusext@ops.ietf.org
> Objet : RE: Chargeable-User-Identity
> 
> 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/>
> 

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