[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Possible Resolution to Issue 198: Attribute Concatenation/Splitting
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: email@example.com
Date first submitted: June 30, 2006
Comment type: 'T'echnical
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).
BTW, do the same issues also apply to the NAS-Filter-Rule AVP defined in
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).
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
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
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
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.