[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: CUI - issues addressed in version 3
Barney, Farid,
Some thoughts and comments inline.
Cheers,
Jouni
> -----Original Message-----
> From: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Barney Wolff
> Sent: 16. joulukuuta 2004 9:17
> To: Adrangi, Farid
> Cc: radiusext@ops.ietf.org
> Subject: Re: CUI - issues addressed in version 3
>
> On Wed, Dec 15, 2004 at 04:47:32PM -0800, Adrangi, Farid wrote:
> >
> > It seems to me the advertisement capability generating more
> heat than
> > light! Actually, I am not sure if the advertisement capability is
> > really required as I stated in my previous e-mail (on a different
> > thread). What if we remove the advertisment capability
> and simply say
> > this:
> >
> > "
> > In cases where the home RADIUS server cannot determine the
> NAS support
> > for the CUI, if the home RADIUS server requires the NAS
> support for CUI
> > for any reason (e.g., for billing or charging purposes),
> the home RADIUS
> > server MUST reject the request by sending an Access-Reject message
> > including an Error-Cause attribute [RFC3576] with value
> (to-be-defined)
> > (decimal), "CUI-Support-Undetermined". Otherwise, if the
> authentication
> > is successful, the home RADIUS server MUST send both the
> User-Name (1)
> > attribute and the CUI attribute, with the understanding
> that if the NAS
> > supports the CUI attribute the CUI attribute will override
> the identity
> > portion the User-Name (1) attribute. That is, the User-Name(1)
> > attribute will be used for routing and the CUI attribute
> will be used
> > for identity purposes. When an Access-Accept without the
> CUI attribute
> > is received, if the NAS requires the CUI attribute to be
> present in the
> > Access-Accept, the NAS SHOULD treat the Access-Accept as a reject.
> > "
> >
> > Is this aligned with your thoughts?
>
> The last part is. For the server, I cannot understand the case where
> the server's owner demands CUI but the NAS/Proxy owners did not: the
> server can always use Class*. Sending back User-Name risks
> the routing
> problems that motivated a separate CUI.
I agree with Farid here that probably the whole advertising of CUI is
not
needed. The CUI is either required or not and the decision of requiring
CUI
should be defined by organizations utilizing CUI for their
business/deployment
models. If peer NAS/Proxy/Server doesn't understand CUI in a context of
the used
business/deployment model it should be considered broken?? (e.g that's
why
various organizations define RADIUS profiles for their use cases)
> * Let's not claim that Class is unreliable, or truncated, but
> somehow CUI
> will avoid such problems. Anyway, it's the server that gets to put in
> the first Class attribute, so if truncation is a problem it
> will be boxes
> upstream that suffer it.
>
> > > The vagueness is, I think, in whether there needs to be a 1:1
> > > relationship
> > > CUI<->real_user and if so over what period. "Valid" does not
> > > capture the
> > > business requirement, which seems to be that the proxy/NAS
> > > owner demands
> > > to be able to recognize that two sessions were initiated by
> > > the same user,
> > > if I have understood things correctly. Or perhaps I have it
> > > backwards,
> > > and the requirement is to be sure that two sessions were
> initiated by
> > > different users!
> >
> > IMO, even 1:1 relationship CUI<->real_user is also out of
> scope. For
> > clarify maybe the paragraph should be rephrased as below:
> > "
> > The CUI format (i.e., User-Identity types listed above) and
> > configuration (e.g., CUI lifetime) will be determined based on
> > business/deployment decisions by the *home network*.
> Standards bodies /
> > organizations like 3GPP and GSMA will be responsible for
> defining how
> > the CUI should be formatted and configured based on their security /
> > deployment requirements and business needs.
> > "
>
> This doesn't fly, if it is the NAS/proxy owner that's requiring CUI.
> Surely the binding lifetime is part of that requirement. I'm
> not concerned
> with the value per se (that can always be configurable) but with its
> interpretation. For example, if lifetime is 1 hour, does
> that mean from
> one session start to the next, or from session end to the next session
> start, or simply that the binding can change each hour of the day, so
> might change between sessions starting at 09:59 and 10:01?
> Can a developer
> write a RADIUS server that will work in any application?
I really fail to see what is the problem here. CUI can change between
two authentications (or sessions how you want to see it), but should
that
be a problem? CUI may last over several RADIUS determined or user
determined sessions and the NAS/proxy should be prepared for that. CUI
is not identifying sessions per se. However, a backend billing
system may use CUI to combine several related RADIUS accounting session
into one longer "billed entity" for an user identified by CUI.
There are business/deployment models where the NAS/Proxy is required to
use CUI within the model the NAS/proxy owner wants to be part of. And
still the home network/server determines the lifetime of the CUI and the
mapping of the CUI<->real_user. Why should the NAS/proxy care about the
lifetime or mapping of the CUI -- if it just echoes CUI back or copies
CUI to some other "interoperator billing system data records" generated
in the visited network?
> If those demanding CUI have been specific enough to answer
> such questions,
> I've missed it.
>
> Barney
>
> --
> Barney Wolff http://www.databus.com/bwresume.pdf
> I'm available by contract or FT, in the NYC metro area or via
> the 'Net.
>
> --
> 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/>