Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt )

["Alan DeKok" <aland@ox.org>]

Bernard Aboba <aboba@internaut.com> wrote:
> [ re: location ]
>
> However, I don't see a need for "Capabilities Announcement" by the NAS. 

  I agree.  For the larger capabilities case, I see the requirements
as follows:

 a) NAS requires information from the RADIUS server
 b) RADIUS server requires the NAS implement X

  For (a), the NAS can simply drop any session where it doesn't get
the information it needs.  The NAS *MUST* also advertise the
information it needs in Access-Request packets, otherwise the RADIUS
server won't know to send the information.  (The format of this
advertisement is less of an issue.)

  For (b), the current RADIUS spec says that it's permissible for
NASes to ignore attributes they don't understand, making (b)
impossible to satisfy in the current RADIUS system.

  The solution discussed previously is two-fold.  For existing RADIUS
conversations that use Access-Challenge, a "capability request"
attribute can be sent by the RADIUS server to the NAS.  In order to be
sure that the NAS supports that capability, the NAS must reply with an
"capability ack" in the next Access-Request.

  For RADIUS conversations that don't use Access-Challenge, the
solution is to extend them to use Access-Challenge.  This is
"fail-safe" under the current design, in that existing implementations
will treat unsupported Access-Challenge as reject.  The method above
for capability exchange can then be used to enforce capability
requirements.

  In conclusion, I think a capabilities protocol outlined as above
would be very useful, and would fit in with existing RADIUS
deployments and practices.

  Alan DeKok.

--
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/>