[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Filter Separation using a NUL?



Hi,

On Thu, Oct 19, 2006 at 01:52:39AM -0700, Glen Zorn (gwz) wrote:

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

As far as I've understood the case so far, there is an encoding defined
for individual rules, but no encoding for a complete rule set. 

The knowledge of where each rule begins and ends therefore needs to be
transported out of band, along with the rule set string. 

DIAMETER uses separate attribute instances for that purpose; what's just
been proposed is that RADIUS uses NUL characters instead. Thus, we first
define a single long rule set string, and then say that it is to be
transported in a 0-1 "single long" attribute (which is formed by
concatenating all instances of a string attribute in their order of
appearance in the packet).

Cheers,


Emile.

-- 
E-Advies - Emile van Bergen           emile@e-advies.nl      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

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