RE: Issue 113: Attribute Concatenation

[gwz@cisco.com]

Congdon, Paul T (ProCurve) <mailto:paul.congdon@hp.com> supposedly scribbled:

...

>> Actually, Diameter AVPs can be larger than a RADIUS _message_.  If
>> you really want to support fragmentation and reassembly in the
>> general sense, then you need to deal with that, too.
>> 
> 
> I probably should have been more clear about using the words 'general
> sense'.  All we are talking about is the string in the
> Qos-Filter-Rule that might be too large to fit in the current Radius
> version of the attribute.  I am under the assumption that handling
> this type of scenario is common practice in Radius/Diameter proxies
> and that is has been documented in a previous RFC, but perhaps I'm
> wrong on this.   

OK, I'm a bit confused here: is this Qos-Filter-Rule generated by a RADIUS server, a Diameter peer or either?
  
> 
> I still think the existing text explains the issue and solution fairly
> clearly:
> 
>          The Text field contains a QoS filter, utilizing the syntax
>          defined for the QoSFilterRule derived data type defined in
>          [RFC3588], Section 4.3.  Note that this definition contained
> an 
> 
>          error, so that the complete syntax is described in the
>          definition of the QoS-Filter-Rule AVP, defined in [NASREQ].
> 
>          The RADIUS server can return multiple QoS-Filter-Rule
>          attributes in an Access-Accept or CoA-Request packet. Where
>          more than one QoS-Filter-Rule Rule attribute is included, it
> is 
> 
>          assumed that the attributes are to be concatenated to form a
>          single QOS filter.
> 
>          Whereas the maximum allowable message size in [NASREQ] is
>          greater than RADIUS' maximum allowable message size, it is
>          assumed that QOS filters that exceed RADIUS' allowable
>          message size will be broken into multiple QoS-Filter-Rule
> attributes by 
> 
>          the RADIUS server and concatenated back into a single QOS
>          filter by the NAS.

But this makes no sense to me at all.  Do you mean "Whereas the maximum allowable AVP size in [NASREQ] is greater than RADIUS' maximum allowable attribute size, it is assumed that QOS filters that exceed RADIUS' allowable attribute size will be broken into multiple QoS-Filter-Rule
attributes by the RADIUS server and concatenated back into a single QOS filter by the NAS"?

> 
>          As per the requirements of RFC 2865, Section 2.3, if multiple
>          QoS-Filter-Rule attributes are contained within an Access-
>          Request or Access-Accept packet, they MUST be maintained in
>          order. The attributes MUST be consecutive attributes in the
>          packet. RADIUS proxies MUST NOT reorder QoS-Filter-Rule
>          attributes.

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

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