David,
I agree that introducing a policy of "always advertise a capability attribute" has it's own issues, as you and Barney pointed out it requires the server and/or the intermediary to keep state of NAS capabilities.
This may not scale well in a WLAN roaming scenario with intermediaries, as it requires the intermediary to keep track of NAS capabilities and to proxy this capability advertisement to all potential Servers when the capability advertisement message is received, and to keep state in order to sync up a Server which went down and came back online.
All servers with customers subscribed to roaming capability will receive capability advertisements from all access points allowing in-roaming visitors.
All home servers would have to keep state about all NASes which allow roaming, unless the intermediary keeps this state and applies an always advertise policy on behalf of a NAS when proxying.
If we want to maintain a stateless architecture, we either need to use the "always advertise" policy or allow the NAS to leverage the state it already keeps - sending a second access-request in response to the server rejecting with a reject reason or capability attribute pointing to the lack of advertisement of one or multiple supported but previously un-advertised capability.
And yes, I love KISSes, but not too many.
Lothar
-----Ursprüngliche Nachricht-----
Von: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]
Gesendet: Dienstag, 14. Dezember 2004 18:20
An: radiusext@ops.ietf.org
Betreff: RE: backwards compatible introduction of NEW attribute such as CUI
Paul Congdon writes...
> 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.
I'm sure that method could be made to work. However, it does make RADIUS somewhat more statefull that it has been heretofore. My thoughts on this are that one more attribute in an Access-Request message is not a great deal of overhead. Given that many RADIUS transactions these days use EAP-TLS (or some other X.509 Certificate based methods) the number of protocol octets consumed by constant advertising becomes diminishingly small, compared to the total authentication session data flow.
--
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/>