Possible Resolution to Issue 198: Attribute Concatenation/Splitting

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

I am wondering if the following approach to the concatenation/splitting 
problem with NAS-Filter-Rule might work:

a.  Add a single octet Tag field:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |    Length     |      Tag      |      String...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

b.  Specify that a multiple NAS-Filter-Rule attributes with the same value 
of the Tag field represent a single rule and are to be concatenated when 
translating to Diameter NAS-Filter-Rule.

c.  Prohibit reordering of NAS-Filter-Rule attributes.

d. Suggest that ASCII values (e.g. '1'=0x31, etc.) be used in the tag field 
so they can be entered easily.



---------------------------------------------------------------------
Issue 198: Attribute Concatenation/Splitting
Submitter names: Pasi Eronen
Submitter email address: pasi.eronen@nokia.com
Date first submitted: June 30, 2006
Reference: http://ops.ietf.org/lists/radiusext/2006/msg00640.html
Document: Filter-00
Comment type: 'T'echnical
Priority: S
Section: 2 and 4
Rationale/Explanation of issue:
Section 2 currently says that "Where more than one NAS-Filter-Rule
attribute is included in a RADIUS packet, the attributes MUST be
consecutive and it is assumed that the attributes are to be
concatenated to form a single filter list."

I guess this means that a single long rule can be split into multiple
NAS-Filter-Rule attributes? And a single NAS-Filter-Rule attribute
could contain pieces of multiple rules? If so, I'd recommend
separating the individual rules somehow. In the current version of
NAS-Traffic-Rule each individual rule ends with LF, making it easy to
determine where one rule ends and another one begins. I'd suggest
adopting this same convention for RADIUS NAS-Filter-Rule.

This concatenation/splitting has also implications for Diameter
translation (Section 4): AVPs coming from Diameter side may have to be
split to several RADIUS attributes (and rule delimiters added), and
attributes coming from RADIUS side have to be concatenated/split to
Diameter AVPs (and rule delimiter removed).
[Pasi Eronen]
> BTW, do the same issues also apply to the NAS-Filter-Rule AVP defined in 
> RFC 4005?

As far as I can tell, no: in RFC 4005, a single AVP always contains
one complete rule (long rules are not split into multiple AVPs, and
one AVP never contains multiple rules).
[Rajith R]
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
[Pasi Eronen] 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.

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