Re: backwards compatible introduction of NEW attribute such as CUI

- Infact an Accounting-ON could have been used to send this attribute. But for some networks, accounting is not mandatory. So we need a mechanism to create a new message like "NAS registration". Also I can guess one more application for this new message. Some stateful Radius server/proxies currently don't know when to cleanup the "hanging sessions" incase NAS crashes. May be this "NAS registration" message can be used to know that the NAS has come up again.

But the question are the new message types are allowed in charter?

- Your second suggestions is to have some configuration on Radius server about NAS. I believe this kind of information regarding the NAS already exists in some implementation of Radius server. For instance a popular Winows based Radius server can differentiate whether NAS supports some specific "set" of Vendor specific attributes or not. But this idea may suffer when you have a long "varied" list of attributes.

"Congdon, Paul T (ProCurve)" wrote:

Instead of sending these 'advertised' attributes in every Access-Request, why doesn't a NAS send a single Access-Request for itself that advertises all the things it needs to advertise once. This 'self generated' Access-Request could occur at start-up time or anytime configuration changes such that new things need to be advertised. Perhaps a new attribute like 'NAS registration' would be required to be included, followed by a list of 'advertised' capabilities that the AS would 'remember' for this NAS.

Paul

From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Lothar Reith
Sent: Tuesday, December 14, 2004 5:35 AM
To: 'Nelson, David'; 'radiusext@ops.ietf.org'
Subject: AW: backwards compatible introduction of NEW attribute such as CUI

Dave,
apologies regarding the repeated use of HTML format, I have now corrected the problem which made me believe I sent in text only format, but infact it got converted to HTML.
I like to comment on your statement:
David Nelson wrote:
You seem to think the "supports CUI but did not advertise" scenario is reasonable, and I disagree. I really can't comment, other than to repeat myself."
I continue to believe that "supports CUI but did not advertise" is a possible scenario.
It is IMO an implementation decision of the NAS manufacturer to allow this or not, and a configuration decision of the network access provider to adopt an always advertise policy or not, unless the specification says "MUST advertise".
If you want to exclude this implementation decision and configuration decision, than the text should say: if CUI is supported, it MUST be advertised in all Access Request Messages.
So far, this has nothing to do with capability negotiation.
Capability negotiation type functionality would only come into play, when the NAS makes an additional implementation decision complemented by the network access operator making a configuration decision to apply a "advertise only on as needed basis" policy.
When such "advertise only on as needed basis" policy is in place, the NAS could on receipt of a Access-Reject with failure cause "CUI-not-determined" delay sending the reject message to the client, and rather send a second access-request with the CUI-NUL attribute to the server, hoping to get back an Access-Accept in time in order to be able to proceed with accepting the user. Are you aware of any standard which would be violated by such an implementation specific behaviour of a NAS ?
Lothar

-----Ursprüngliche Nachricht-----
Von: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]
Gesendet: Freitag, 10. Dezember 2004 17:41
An: radiusext@ops.ietf.org
Betreff: RE: backwards compatible introduction of NEW attribute such as CUI
Lothar Reith writes (still in HTML!)...
> to a) what would be "the appropriate helpdesk" in a WLAN roaming
> scenario ?
This is an important question for those in the "roaming consortium" business, as well as home ISPs, to answer. I remember the "bad old days" before seamless roaming for cellular telephony. Only the brave and the technically savvy were able to use roaming services effectively. Today, I expect to be able to dial 611 on my cell phone wherever I am and get appropriate assistance. (Of course, talking to a human still requires an Act of Congress -- but I digress :-) If WLAN roaming wants to be successful, IMHO, the industry needs to make it as transparent as cellular roaming.
> Also, should the error message say: did not support CUI or perhaps
> supports CUI but did not advertise ?
You seem to think the "supports CUI but did not advertise" scenario is reasonable, and I disagree. I really can't comment, other than to repeat myself.
> A related question is if the server counts an authentication request
> rejected due to missing knowledge about the NASes CUI support as an
> unsuccessful login attempt with regards to security thresholds ?
That is likely an implementation decision. Personally, I would tend to count it as "failed to meet policy requirements" as apposed to "failed to authenticate".
--
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/>