[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: CUI - issues addressed in version 3
Barney,
> 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.
The server doesn't care about CUI and the text needs to be reworded.
Farid and I are currently reworking the words.
Regarding binding issue:
> 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?
>
> If those demanding CUI have been specific enough to answer
> such questions, I've missed it.
So we agree with your statement in general. The binding lifetime is part of
the requirement. But just to make it perfectly clear it is only relevant to
the opaque CUI format.
Your concerns are correct. The difference is that we belive that it is
really up to an SDO or the business relationship to nail down the issues you
serve up.
The reason we belive that we can't specify these issues is that each SDO
will have different requirements here. We are simply providing them with the
tools to do it.
So for example in the case of Opaque CUI. One SDO may say that a different
Opaque CUI will be generated at the start of a billing period. Another SDO
may specify that the first 4 octets of the Opaque CUI will contain a
validity timestamp.
Also the 1:1 relationship is an SDO matter. We can say that it is 1:1 but I
don't think it is necessary. The business agreement between roaming
partners will define the semantics.
See further inline:
> -----Original Message-----
> From: Barney Wolff [mailto:barney@databus.com]
> Sent: Thursday, December 16, 2004 2:17 AM
> 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.
We agree. We need to change the words here. The Home Network does not care
about CUI. The home network can always use class - even when trunctated and
even if only one is supported by the NAS. And, even when class is not used.
We have been doing this for years. But this is not about the home network
as you point out.
> * 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.
Right!!!.
> > > 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?
>
> 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/>