[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: backwards compatible introduction of NEW attribute such as CUI

Title: AW: backwards compatible introduction of NEW attribute such as CUI
 
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/>