Re: Chargeable-User-Identity

[Stefan Winter <stefan.winter@restena.lu>]

Hi,

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

Oh! Cute. That's exactly the thing. Thanks!

Now the only problem is to find RADIUS servers that support the unusual
encoding of 5580 attributes to parse the content of Operator-Name. But
that's not for this mailing list to solve :-)

Greetings,

Stefan Winter

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


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