Proposed Resolution to Issue 198: Attribute Concatenation/Splitting

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

The text of Issue 198 is enclosed below.  The proposed resolution is as 
follows:

Change Section 2 to the following:

"2.  NAS-Filter-Rule Attribute

  Description

     This attribute indicates filter rules to be applied for this user.
     Zero or more NAS-Filter-Rule attributes MAY be sent in Access-
     Accept, CoA-Request, or Accounting-Request packets.

     The NAS-Filter-Rule attribute is not intended to be used
     concurrently with any other filter rule attribute, including
     Filter-Id (11) and NAS-Traffic-Rule [Traffic] attributes, and
     SHOULD NOT appear in the same RADIUS packet.  If a Filter-Id
     attribute is present, then implementations of this specification
     MUST silently discard NAS-Filter-Rule attributes, if present.

     Where more than one NAS-Filter-Rule attribute with the same non-
     zero Tag field value is included in a RADIUS packet, the String
     field of the attributes are to be concatenated to form a single
     filter.  As noted in [RFC2865] Section 2.3, "the forwarding server
     MUST NOT change the order of any attributes of the same type", so
     that RADIUS proxies will not reorder NAS-Filter-Rule attributes.

     A summary of the NAS-Filter-Rule Attribute format is shown below.
     The fields are transmitted from left to right.

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

  Type

     TBD

  Length

     >=4

  Tag

     The Tag field is one octet, and MUST always be present.  It is
     used to identify the filter rule that is represented.  Where a
     single filter rule exceeds 253 octets in length, the rule MUST be
     encoded across multiple NAS-Filter-Rule attributes, each with the
     same Tag value; Tag values MUST be unique for each filter rule
     present in a RADIUS packet with the exception of a Tag value of
     '0' (0x30).  The value of '0' (0x30) in the Tag field indicates
     that the attribute contains a filter rule that does not exceed 253
     octets in length; as a result attributes with a Tag value of 0x30
     MUST NOT be concatenated, and one or more Filter-Rule attributes
     with a tag value of 0x30 may be included in a single RADIUS
     packet, each describing a single filter rule.

  String

     The String field is one or more octets.  It contains filter rules
     in the IPFilterRule syntax defined in [RFC3588] Section 4.3.
     [RFC3629] UTF-8 encoded 10646 characters are RECOMMENDED, but a
     robust implementation SHOULD support the field as undistinguished
     octets."

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



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