[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RADIUS to Diameter gateways & extended attributes

At 3/21/2006 02:08 PM, you wrote:

  Some issues were raised during the WG meeting today.  I'll try to
address them here.

  The purpose behind using the Diameter format to carry extended
RADIUS attributes is to simplify the work done by RADIUS to Diameter
gateways.  As a result, any issue of Diameter to RADIUS gatewaying and
attribute/message size is largely out of scope.

  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.
I'd like to hear from people that actually have such things, as we didn't get very many responses in the Dime meeting room. I'll chase that in a different thread. 



  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.

  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.


We already have this.  It's the Origin-AAA-Protocol AVP (AVP Code 408)
RFC 4005, Section 9.3.6



  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.

  Alan DeKok.

--
Right, but I don't think that's actually the problem Glen is chasing, but I'll leave that to him. 

Dave.



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