RE: Issue: Attribute concatenation/splitting

["Nelson, David" <dnelson@enterasys.com>]

Alan DeKok writes...

>   If one rule can span multiple NAS-Filter-Rule attributes, then it
> needs a "terminate this rule" that is independent "terminate this
> attribute".

While the text in RFC 3588 and RFC 4005 could, IMHO, benefit from some
clarification, it appears to me that the Diameter NAS-Filter-Rule AVP
{RFC4005] contains one instance of the derived data type IPFilterRule
[RFC3588], which appears to describe a single rule.  If this is correct,
the only situation in which a rule would span multiple RADIUS
NAS-Filter-Rule Attributes is when the rule text exceeds 253 octets.
While this is theoretically possible, the formal syntax of IPFilterRule
tends to limit the likelihood for this to occur.  Or so it would seem to
me.

>  A CR, LF, or combination can do that, in which case the
> problem of attributes of length 2 doesn't exist, because the packing
> methods prohibit it.

I'm not in favor of ASCII delimiters for sub-strings within strings.
This is effectively "value packing" i.e. encoding multiple values in a
single value field of an RADIUS TLV.

>   If one rule cannot span multiple NAS-Filter-Rule attributes, then
> there is no problem, because an attribute of length 255 has no special
> meaning.

It would be an interesting exercise to see if it is possible to specify
an instance of the IPFilterRule derived data type that is longer than
253 octets.

>   On the other hand, if one rule can span multiple NAS-Filter-Rule
> attributes, then you might as well give up on trying to match rules to
> attributes.  Pack all of the rules together in one long string, and
> then chop the string every 253 bytes to encode it into NAS-Filter-Rule
> attributes.  So there will be no special meaning for attributes of
> length 255, so there will be no problem.

Ugh.

>   With this last method, we would presume that any implementation that
> needs to be able to add/delete rules would know about the packing
> methods, and be able to unpack/add/pack the rules into attributes.
> This would tend to break backwards compatibility with older RADIUS
> servers, so they wouldn't be able to edit the rules, though.

Right.


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