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

[Emile van Bergen <openradius-radextwg@e-advies.nl>]

Hi,

On Fri, Sep 09, 2005 at 03:14:32PM -0400, Alan DeKok wrote:

> "Avi Lior" <avi@bridgewatersystems.com> wrote:
> > The only debate that we are having which is specific to Location is
> > whether or not the NAS advertizes its location capabilities in the
> > access request.  Well Bernard thinks no, I think yes.  But regardless of
> > that specific debate we already have evidence that a mechanism for
> > advertizing the NAS capability is required -- CUI and Prepaid etc.....
> 
>   If that advertising mechanism is general, then it can be shared
> across all capabilities, meaning this isn't a strictly
> location-capability problem.
> 
>   I would also expect that NASes will *not* want to send all of the
> available information for all capabilities.  

Seriously though, if that's information that's actually relevant at
authentication time, ie. required to determine the level of access, why
not?

If it's trust, see my other post about it.

If it's packet size, then it seems we're trying to solve the problem at
way too high a layer.

If it's efficiency, extra round trips and extra state are far more
costly than a few more bytes in an access request.

> Rather, they should send an Access-Request with an "extended
> capability" notification, and leave additional negotiations to later
> stages of the authentication conversation.

The only purpose I see for any sort of capability advertising in RADIUS
is that a NAS can tell in advance that it will act on an authorization
attribute.

Most prominent example (and a real world one I had to deal with): if a
NAS does not support IP filtering attributes, it's allowed to ignore
them (like any other attribute), while the home AAA would want to make
its accept/reject decision conditional on whether or not the NAS will
actually apply the filter. 

But at the RADIUS level, we already have a mechanism for that: the
inclusion of the relevant response attribute, possibly with a dummy or
null value, in the access request. 

Normally the value is used as a hint for the response, but it also tells
the server that the NAS knows about the attribute. It does not seem a
big change to specify that the NAS MUST NOT include hints in access
requests for attributes that it does not support in access accepts.

If even that's is too much to ask, and you want to transport the list of
supported attributes in a slightly more compressed way, I suggest a
variable length bitmap, where each numbered bit from LSB to MSB conveys
the supported status ('NAS will heed') of the correspondingly numbered
IANA attribute. But you'd need similar language anyway ("Do not set the
bit unless you actually intend to honor the attribute").

Cheers,


Emile.

-- 
E-Advies - Emile van Bergen           emile@e-advies.nl      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

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