RE: Hints and End-to-End capabilities

["Nelson, David" <dnelson@enterasys.com>]

Emile van Bergen writes...

> Other than backwards compatibility, the hints mechanism has another
> advantage: it can allow the home AAA to discover the capabilities of
the
> whole chain, because proxies can, and often unintendedly do, indicate
> their policies with respect to response attribute filtering by
> performing request attribute filtering in the same way.

Yes.  It seems that the attribute filtering behavior of proxy servers
varies widely, so it would need to be taken into account in any
end-to-end scenario.  Adding a new attribute that contains the
aggregated capabilities advertisement from the NAS would seem to be of
little use in proxy chairs where at least one proxy server edits out
attributes that it doesn't understand (implement).

> However, there are cases it may be undesireable for a proxy to filter
an
> attribute from a request that it does intend to filter from any
> response. Attributes that are required in access requests or that only
> make sense in those will be among them.

Agreed.
 
> Looking at all that, the dedicated bitmap attribute seems better: the
> proxy can clear bits that correspond to attributes it doesn't allow
the
> home AAA to set, without filtering required request attributes.

Unless, of course, one proxy in the chain decides to filter out the new
bitmap attribute that it does not understand.  This sort of behavior
severely hampers the intended forward compatibility proposition of
RADIUS.  It would be well to understand if this is a prevalent practice.

 
> On the other hand, there will be proxies that will filter response
> attributes but that do not (yet) know about the NAS-will-heed-bitmap.
> And those will still cause access accepts to be received by the NAS
that
> are less restricted than the home AAA intended them to be.

I think the issue you are raising is that, in some proxy deployments,
the notion of end-to-end capabilities advertisement may be a fiction.
When proxies filter unknown attributes, it quickly degenerates to a
series of hop-by-hop capabilities advertisements.

> At any rate, I think that 'NAS-through-proxies-will-obey-attribute-X'
> advertisements are the only capability advertisements that really add
> something to the protocol.

Agreed.  The difference between a single bitmap attribute and a
collection of hint attributes instances is PDU encoding efficiency.  I
would argue, however, that if hints cannot be made to work reliably in a
given proxy chain scenario, then the bitmap attribute will similarly
fail. 
 
> The whole idea with RADIUS is offloading policy to a central place, by
> asking the server about each individual session that's about to take
> place. And you only even get to see a user's policy if you supply that
> user's credentials. No pushing or publishing of parts of it up front.
> That's an aspect of RADIUS that should remain unchanged, I think. It
> makes security analysis so much easier.

Saying this another way, RADIUS has always been about what the Server
wants the NAS to do.  NASes have been seen as simple and obedient.
Dynamic RADIUS has changed this, to the extent that the NAS can be take
on the "server" role for CoA.  The introduction of the notion that the
NAS may have policy requirements of the Server is entirely new to
RADIUS.

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