Issues & fixes (was Re: Tagged attibutes )

["Alan DeKok" <aland@nitros9.org>]

Tomasz Wolniewicz <Tomasz.Wolniewicz@uni.torun.pl> wrote (edited):
>   I have recently got hit by  a VLAN setting problem and lack of
> interoperability between ZZZ Radius server and 3COM access-point.
> As it turned out, it seems that the access-point does not handle tagged
> attributes. On the other hand ZZZ does a strange thing when one
> does not specify the tag.  I looked at RFC 2868 and found out that it is
> impossible to tell who gets things wrong. The RFC says:
> 
> 3.6.  Tunnel-Private-Group-ID
> 
> ....
> ....
> 
> The Tag field is one octet in length and is intended to provide a
>       means of grouping attributes in the same packet which refer to the
>       same tunnel.  If the value of the Tag field is greater than 0x00
>       and less than or equal to 0x1F, it SHOULD be interpreted as
>       indicating which tunnel (of several alternatives) this attribute
>       pertains.  If the Tag field is greater than 0x1F, it SHOULD be
>       interpreted as the first byte of the following String field.
> 
> So we know what to do if the tag is greater then 0. But what do we do it
> it is equal to zero? 

  My opinion is that the tag should be suppressed, and not put into
the attribute.

> the RFC does not say that it MUST NOT be equal to zero. FreeRadius
> seems to handle tags equal to zero well, but if you try to set a tag
> to zero in the configuration, the FreeRadius will simply send an
> untagged value. ZZZ, however sets the tag to 0 and there seems
> to be no way to make it to send an untagged value.

  If the other server sends a tag with value zero, the client SHOULD
ignore it.

> My 3COM AP obviously has a problem that it does not handle tags greater
> then 0 but with those equal to 0 things are not so clear.

  It would appear then that the problem mainly lies with the AP, which
implements support for tagged attributes... so long as they don't have
a tag.  If the other RADIUS server can't be made to suppress the tag
of zero, then there is an interoperability problem.

> So my point is - don't you think that RFC 2868 should be fixed as well
> and that such a thing would fit into the draft that you are co-authoring?

  We could mention it in the "issues and fixes" document.  Client
implementations that support tagged attributes, but don't support the
tag in those attributes are... odd.

  Alan DeKok.

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