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

RE: Issue: Diameter-RADIUS gateway behavior not completely specified

I think the major issue here is translation from Diameter to RADIUS in the case where the translated RADIUS packet does not fit within the maxium (4096) byte packet size. Is that correct?
This problem is not unique to the NAS-Filter-Rule, so if possible I'd prefer a general solution, rather than one specific to NAS-Filter-Rule. 

My take is that a solution:
a. Needs to notify the Diameter client or server of the problem so that it can be logged and hopefully fixed; 

b. Needs to avoid sending an illegal RADIUS packet.
The way to think about this is that the Diameter/RADIUS proxy conceptually translates the Diameter message to a RADIUS packet and then checks whether it fits within the length constraints. If not, then it needs to translate the oversize RADIUS packet to something else rather than sending it. This problem can even occur in other scenarios, such as a RADIUS proxy which attempts to add a Proxy-State attribute but finds that the packet exceeds the 4096 octet size limit.
My suggestion is to translate an oversize RADIUS Access-Accept into a RADIUS Access-Reject with an Error-Cause attribute of value 505 "Other Proxy Processing Error ". Not sure what Diameter error message would be appropriate.
In the case of server-initiated messages, I think the correct thing is to translate an oversize RADIUS CoA-Request to a Disconnect-Request, also with Error-Cause value 505. 


==========================================================
Description of issue: Diameter-RADIUS gateway behavior not completely specified 
Submitter name: Glen Zorn
Submitter email address: gwz@cisco.com
Date first submitted: 26 Aug 06
Document: draft-ietf-radext-filter-01.txt
Comment type: T
Priority: 1
Section: 4
Rationale/Explanation of issue: The last sentence of section 4 says
"Note that since a Diameter AVP can be larger than the maximum RADIUS
packet size (4096), translation from Diameter to RADIUS may not be
possible in all cases."  While this is true, the behavior of the
Diameter-RADIUS gateway in this case is left unspecified.  Is the
response forwarded back toward the requests' originator without the
untranslatable AVPs?  In the case of an Access-Accept message, Section
1.2 says "If a NAS conforming to this specification receives an
Access-Accept packet containing a NAS-Filter-Rule attribute which it
cannot apply, it MUST act as though it had received an Access-Reject.",
it might be reasonable for the gateway to translate the Access-Accept
into an Access-Reject, since an attribute that is missing because
untranslatable can obviously not be applied.  In the case of a CoA
message with an untranslatable attribute, should the message be
translated into a Disconnect-Request or just discarded?  Or in both
cases, should the gateway respond to the originating/responding Diameter
peer with an appropriate error (e.g., DIAMETER_INVALID_AVP_LENGTH) and
let it figure out the next step?  If so, it still seems that the peers
behavior must be specified.

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




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