RE: Issue: Attribute concatenation/splitting

[Rajith R <rajithr@huawei.com>]

See comments inline

************************************************************************
****
This e-mail and attachments contain confidential information from
HUAWEI, which is intended only for the person or entity whose address is
listed above. Any use of the information contained herein in any way
(including, but not limited to, total or partial disclosure,
reproduction, or dissemination) by persons other than the intended
recipient's) is prohibited. If you receive this e-mail in error, please
notify the sender by phone or email immediately and delete it!

>>-----Original Message-----
>>From: owner-radiusext@ops.ietf.org
[mailto:owner-radiusext@ops.ietf.org]
>>On Behalf Of Pasi.Eronen@nokia.com
>>Sent: Monday, July 03, 2006 4:30 PM
>>To: rajithr@huawei.com; bernard_aboba@hotmail.com;
radiusext@ops.ietf.org
>>Subject: RE: Issue: Attribute concatenation/splitting
>>
>>rajithr@huawei.com wrote:
>>
>>> AFAIK, splitting & concatenation are necessitated by the 255 byte
>>> limit for RADIUS attributes. So it would be better to split at 253
>>> byte (for the attribute payload) boundary rather than LF or some
>>> other attribute specific delimiter, I think this would have the
>>> advantage of
>>> * same & simple logic for concatenation/splitting of any
>>> suitable RADIUS attribute of length > 255
>>> * packing efficiency in the message, though not a principal concern
>>
>>This simple concatenation/splitting works when you need to include a
>>single, potentially long data item (e.g. EAP-Message) in a RADIUS
>>message. But it gets complex if you need to include multiple,
>>potentially long data items of the same type (in this case, individual
>>filter rules) and you need to maintain the boundaries between the
>>individual data items somehow.

IMHO, split/concatenate logic for multiple, potentially long data items
of the same type should be attribute type insensitive. One such option
could be split at 253th byte boundary of the payload and add them
successively to the RADIUS message. If the last (split) RADIUS attribute
also happens to be of attribute length = 255, add a delimiter attribute
(of the same type) with attribute length as 2.

>>
>>In particular, if we decide to support individual filter rules longer
>>than 253 characters, it looks like a RADIUS-to-Diameter translation
>>agent will need code specific to NAS-Filter-Rule no matter how we
>>choose to do the concatenation/splitting on the RADIUS side. The
>>difference is just how complex that code needs to be (e.g., is it
>>sufficient just to recognize "LF", or understand the full filter
>>rule syntax).

To convert a RADIUS NAS Filter rule attribute to Diameter, the Diameter
AVP header data should be generated/translated from RADIUS attribute
header data and the attribute payload could be directly copied to the
AVP payload. Only concatenation considerations need to be applied. 


>>
>>Best regards,
>>Pasi
>>
>>--
>>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/>