Proposed Resolution to Issue 202: Diameter-RADIUS gateway behavior not spec'd

["Bernard Aboba" <bernard_aboba@hotmail.com>]

The text of Issue 202 is enclosed below.

The proposed resolution is as follows:

In Section 4, Change:

"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."

To:

"Note that a translated Diameter message can be larger than
the maximum RADIUS packet size (4096).  Where a Diameter/RADIUS
gateway receives a Diameter message containing a NAS-Filter-Rule
AVP that is too large to fit into a RADIUS packet, the
Diameter/RADIUS gateway will respond to the originating
Diameter peer with the DIAMETER_INVALID_AVP_LENGTH error (5014),
and with a Failed-AVP AVP containing the NAS-Filter-Rule AVP.
Since repairing the error will probably require re-working
the filter rules, the originating peer should treat the
combination of a DIAMETER_INVALID_AVP_LENGTH error and
a Failed-AVP AVP containing a NAS-Filter-Rule AVP as a
terminal error."


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