Re: Issues & fixes (was Re: Tagged attibutes )

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

"Nelson, David" <dnelson@enterasys.com> wrote:
> I respectfully disagree.  RFC 2868 also says:
...
> Both the ASCII art and the sentence "If the Tag field is unused, it MUST
> be zero (0x00)." tell me that that Tag Field is not optional.  It is
> always present in these attributes, and if it is not used it is set to
> zero, rather than omitted.

  I agree, and that doesn't invalidate my earlier comments.

  The Tunnel-Type attribute overloads the "integer" types previously
defined in RFC 2865.  The intent was that older RADIUS servers can
treat the 4 octets of "tag + value" as a 32-bit integer, for full
compatibility.  So for "integer" types, the requirement that they be 4
octets means that the tag field MUST be present, and MUST be zero if
unused.

  Let's look at another attribute:

3.3.  Tunnel-Client-Endpoint
...
   A summary of the Tunnel-Client-Endpoint Attribute format is shown
   below.  The fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |       Tag     |    String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
   Tag
      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.
...

  i.e. there is NO requirement here that the tag be set to zero if
it's unused.  This is because this attribute is overloading the
"text/string" types previously defined in RFC 2865.  As many older
servers treat the attributes as C strings, a requirement to always put
a tag of 0 for "no tag" would mean breaking backwards compatibility
with those servers.

  The original question starting this was about
Tunnel-Private-Group-Id, which is also "tag + string".

  If a RADIUS server *always* puts a tag of zero for "no tag", then
there are other servers out there, and probably clients, which will
interpret that attribute as being an empty string.

> Now, I realize that it is possible to omit the Tag Field and parse the
> packet correctly when the first octet of the value field is not a Tag
> and is greater than 0x1F or less than 0x00.  I think that RFC 2868 is
> internally inconsistent in this regard and that we should indeed address
> this issue in the Issues & Fixes document.

  I don't see any inconsistency in RFC 2868.  I see that the
requirement to be backwards compatible is more important than the
requirement to always put a tag in a "string" attribute.

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