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

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

Alan DeKok writes...

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

I respectfully disagree.  RFC 2868 also says:

<quote>

   A summary of the Tunnel-Type 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       |     Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               Value (cont)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type
      64 for Tunnel-Type

   Length
      Always 6.

   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.  Valid values for this field are 0x01 through 0x1F,
      inclusive.  If the Tag field is unused, it MUST be zero (0x00).

</quote>

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.

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.


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