Re: Capabilities negotiation problem statement

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

"Nelson, David" <dnelson@enterasys.com> wrote:
> What happens to the "extended" RADIUS attribute format including the
> Mandatory bit when the RADIUS PDU passes through a proxy server that
> hasn't implemented the "extended" attribute format?

  Ideally, it passes it through unchanged.

> I suppose this is the same as what happens to any other unrecognized
> attributes at proxy servers...  which is what, exactly?

  "implementation dependent".  So let's look at the error conditions:

 1) proxy drops the attributes, and home server doesn't see them.
    It's likely then, that the home server will need those attributes,
    and the new type of session will fail to meet it's requirements,
    and will be rejected

 2) The proxy passes them as-is, and the home server sees them.
    It's likely, then, that the new type of session will work.

  Looking at (1), if the home server has a way to tell that the new
attributes have been dropped, then the design is fail-safe.
Otherwise, the home server gets a request with missing information,
and may reach the wrong conclusion.

  My initial thought is to extend the RADIUS packet header by
mandating a new RADIUS attribute to be the first one in the packet.
The existence, and placement, of that attribute would signal new
capabilities.  It's content could include things like information
about the other "mandatory" attributes in the packet, such as a simple
count.

  If that attribute was a simple integer, it's impact on RADIUS would
be small, and the likelihood of making it through a proxy chain would
be high.  The other, complex, new attributes may not make it through a
proxy chain, but by "bootstrapping" off of the first attribute, home
servers could detect this fact, and deal with it.

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