[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issues & fixes (was Re: Tagged attibutes )
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 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
> 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.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.