Re: RADIUS to Diameter gateways & extended attributes

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

Hi,

On Tue, Mar 21, 2006 at 02:08:11PM -0500, Alan DeKok wrote:

>   That is, it doesn't matter so much that Diameter can carry much more
> traffic per attribute/message than RADIUS can, because that is not the
> purpose behind the use of the Diameter attribute format.  If that is
> true, we then have to ensure that Diameter to RADIUS gateways don't
> pass large Diameter attributes/messages to RADIUS.
> 
>   Since we already have Diameter to RADIUS gateways that perform this
> enforcement, it would appear that this worry is largely not a problem
> in practice.
> 
>   However... with the advent of many more RADIUS attributes being
> carried in Diameter, it would be good to enable Diameter to RADIUS
> gateways to tell which attributes *can* fit into RADIUS, and which
> cannot.  One suggestion in the "extended attribute" subgroup was to
> allocate the Diameter-format RADIUS attributes from a subset of the
> Diameter space.  The gateways could then trivially tell which
> attributes are RADIUS compatible.

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.

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.

However, a DIAMETER client has a concept of clients NAKing server
responses, if I remember correctly, because there is a class of
attributes for which a server may set the M bit, but that are not
required to be supported on the NAS by the base specification or NASREQ. 

Because DIAMETER servers already have to handle such situations
gracefully, having a gateway NAK overlength responses, longest
attributes first would seem a good approach.

Alternatively, the DIAMETER gateway could first retry by ignoring all
non-M attribute from the DIAMETER response to see if the recoded RADIUS
response fits the limit. If it still doesn't fit, the gateway will still
have to NAK the response.

But if the home DIAMETER server wants to know *in advance* that the
policy it is about to send will actually be applied in full, the whole
generic issue of NAS hints and promises appears, and that's a generic
problem that has little to do with DIAMETER or gatewaying per se.

A DIAMETER gateway in that respect is nothing but a special case of an
response attribute filtering proxy. And all RADIUS proxies do that in
some form or another. This has come up before, and we never finished
that discussion, although I still think that the concept of a client's
promises-to-apply, however encoded, would solve the problem.

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.

>   That suggestion may be problematic if a Diameter server adds
> additional RADIUS compatible attributes to a Diameter message that
> contains attributes previously taken from RADIUS.  There is no way for
> a Diameter to RADIUS gateway to be sure if the attributes fit into a
> RADIUS packet.
> 
>   Another option would be to add a "RADIUS" bit to the Diameter
> attribute.  Any attribute that came from a RADIUS to Diameter gateway
> would have that bit set, allowing later servers to handle them more
> appropriately.
> 
>   I think this addresses Glen's comments.  It doesn't matter how large
> Diameter messages/attributes are if RADIUS servers never see that
> data.  Since the Diameter format is used by the RADIUS servers only to
> *generate* RADIUS compatible traffic, and not to receive Diameter
> traffic, any compatibility issue is pushed to the Diameter side of the
> protocol implementations.

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?

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