Re: Hints and End-to-End capabilities

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

Hi,

On Tue, Sep 13, 2005 at 10:47:42AM -0400, Nelson, David wrote:

> 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).

It /is/ useful. The scenario is this.

a. the home AAA assumes that from its response, nothing but the Code
field (Accept or Reject) will eventually be acted upon by the NAS,
UNLESS

b. it has knowledge, a priori, from hints or a bitmap attribute, that
first, the NAS will act upon certain attributes, and second, the proxy
chain will pass along those attributes.

So if a proxy removes the the capabilities bitmap attribute from the
request, then the result is actually correct: the home AAA may make no
assumptions with respect to the set of response attributes that will be
passed resp. acted upon.

The problem is the reverse: a proxy may pass on unknown request
attributes (incl. the bitmap), but filter all response attributes other
than a well defined set.

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

What I've seen most often is this.

Proxies generally divide upstream AAAs into two categories: servers from
which all response attributes are accepted, and servers from which only
a certain minimal set is accepted.

Sometimes the attribute sets for each of the two home AAA categories can
be defined by the administator.

The behaviour with respect to request attributes varies. Many local
access operators don't want details of their network to leak to the
party with the users database, and will only send the bare minimum set
demanded by the party running the home AAA.

I've always advised customers NOT to provide parties like iPass or GRIC
with a free market survey on who runs what brands of NASes and in what
quantity.

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

Which is what I /want/. End-to-end (ignoring proxy policy) is useless.
The problem is proxies /not/ indicating their filtering policy, by /not/
editing the request.

The idea is that the NAS indicates an initial set of attributes, and the
proxies only subtract from that set, so that the home AAA will know the
set of attributes that WILL be acted upon by the NAS.

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

It depends on the policy change that's easier to mandate. It's either

a. require a proxy operator NOT to pass on request attributes that it does
not intend to pass on from the response (impossible for some attributes)

b. require a proxy operator NOT to pass on a Capabilities-Bitmap
attribute as-is if it filters any attributes from the response (breaks
backward compatibility).

Because if neither requirement is obeyed, the home AAA will get a false
positive, and think that the NAS will receive and act upon a certain
(session limiting) attribute, while it will not.

Of course, the only way to give the home AAA a GUARANTEE that the user
only gets service IF the NAS receives AND acts upon a certain set of
attributes, is an alternative I've also considered and rejected, by
proposing a new value for the Code field, Conditional-Accept.

Such a Conditional-Accept MUST include a bitmap attribute containing the
list of attributes (by number, not position) that MUST be heeded by each
proxy and the NAS in order to interpret the Conditional-Accept as an
Accept.

However, this has the problem of requiring standards action and goes
against the RADIUS philosophy of the serverwhat I expressed in the
paragraph you quoted. not publising policy, only providing final
decisions. 

Also, proxies and NASes that do not support Conditional-Accept, will
silently discard the response (as required by RFC2865, see Section 3),
instead of treating it as a reject, causing needless request
retransmits. So as far as I'm concerned, that option is out.

So that means no ABSOLUTE guarantees at the home AAA while there are
proxies in the field that don't indicate their filtering policy in the
hints/capabilties in the request they pass on, but I think it's the only
way to get there.

The only thing you need at some point is for a home AAA operator to
require his downstreams to run capability-compliant proxies, that is,
proxies that perform the AND operation correctly, ie. only keep those
bits set that correspond to attributes it will forward, and clear all
the others.

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

I don't know if a NAS may have policy requirements from the server. If a
server sends a CoA or Disconnect request to a NAS, the NAS will send a
response as defined in the relevant standards drafts, and it's up to the
server to decide what to do with it.

I see no behaviour at the NAS that's conditional on dynamic knowledge
about the RADIUS server. Which is good, that should /not/ change, in my
opinion.

Kind regards,


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