RE: Filter Separation using a NULL?

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

Bernard Aboba <> supposedly scribbled on Wednesday, October 18, 2006
9:52 PM:

> To clarify Mauricio's question, I've changed the text somewhat. The
> updated text is available for inspection here: 
> 
> http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-filter-03.txt

OK, I'm having a little trouble understanding the point of this & the
reasoning behind it.  I thought that the problem we were trying to solve
was the transmission of a filter set, consisting of one or more rules,
which is potentially larger than the data size of a RADIUS attribute.
Further, the document leads me to believe that it is expected that this
set will be used as such, giving explicit instructions for its
reconstruction on the client ("Where multiple NAS-Filter-Rule attributes
are included in a RADIUS packet, the String field of the attributes are
to be concatenated to form a set of filter rules."); presumably, the
client will need to parse these rules in order to install them, since
the syntax used is that of BSD (not the most popular NAS OS on the
planet, AFAIK).  So what is the point of taking apart this nice set,
parsing it into individual rules, then reconcatenating the
(NUL-terminated) rules into a set again for transmission?  I suspect
that I'm just confused, but maybe somebody can help me out.  

> 
> Here is how the new Section 2 reads:
> 
> 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
>       MUST NOT appear in the same RADIUS packet.  If a Filter-Id or
>       NAS- Traffic-Rule attribute is present, then implementations of
>       this specification MUST silently discard NAS-Filter-Rule
>       attributes, if present.
> 
>       Where multiple NAS-Filter-Rule attributes are included in a
>       RADIUS packet, the String field of the attributes are to be
>       concatenated to form a set of filter rules.  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     |      String...
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
> 
>    Type
> 
>       TBD
> 
>    Length
> 
>       >=3
> 
>    String
> 
>       The String field is one or more octets.  It contains filter
>       rules in the IPFilterRule syntax defined in [RFC3588] Section
>       4.3, with filter rules separated by a NULL (0x00).  One or more
>       filter rules may be included within a NAS-Filter-Rule
>       attribute, and filter rules may be continued across attribute
>       boundaries, so in general implementations cannot assume that
>       filter rules begin and end on attribute boundaries.

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