Re: RADIUS to Diameter gateways & extended attributes

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

Emile van Bergen <openradius-radextwg@e-advies.nl> wrote:
> I think the size related issue can be resolved in a much simpler way.
> Also note that it's not individual attributes that are the problem, as
> much as the total size of the attributes combined.

  Diameter to RADIUS gateways *already* have to enforce:

   a) per-attribute size for RADIUS-compatible Diameter attributes (1..255)
   b) total message size for RADIUS packets

  For *any* format of RADIUS extended attribute, Diameter to RADIUS
gateways will still have to enforce the above restrictions.

> So making the DIAMETER to RADIUS gateway to know what the maximum size
> is for each attribute does not help. It's the total response packet that
> may or may not fit after reencoding using any Extended Attribute
> format.

  Diameter to RADIUS gateways already have this problem when
administrators use Diameter attributes from the RADIUS space (1..255).
They have already implement solutions to this problem.

  Adding a new RADIUS extended attribute changes nothing, except that
the above restrictions must also be applied to the new attributes.

> If the DIAMETER home server allows requests that ultimately come from a
> RADIUS client, then it must expect that any response attribute that
> RADIUS allows to be ignored, can be ignored, with the session being
> allowed to start -- unless the proxy chain and the NAS make certain
> promises in the request regarding the passing and applying of response
> attributes.

  Yes.  It appears we need information in the Diameter message that
"this message is coming from, or going to, a RADIUS system".  I don't
know if Diameter already has that capability.  If not, it would make
the above decisions much easier for Diameter servers.

> The problem does not lie on the attribute number level. A short IP
> filtering attribute would be perfectly fine, whereas a longer one would
> not. Would you want to prohibit the gatewaying of any filtering
> attributes a priori, just because they *can* be longer than the RADIUS
> limit of 4096 minus some?

  No.  But the Diameter server must be able to make an informed
decision.  Failing that, Diameter to RADIUS gateways become almost
impossible to implement robustly.

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