Subject: (radius) Problem with tunnel-auth-06 and Tag

From: "Beadles, Mark A." <[email-masked]>
Date: Wed, 2 Jun 1999 13:34:15 -0400

> The description of how to handle Tag is ambiguous and misleading.  You
> want proof?  Implementations by some of the vendors who authored the draft
> DO NOT INTEROPERATE because they interpret the draft differently, and each
> claims the other is doing it the wrong way.  It's pretty bad when even the
> draft authors disagree on how a protocol is to be implemented.
> 
> The problem is that the text description, and the interpretation, for the
> Tag field is different every time is it used.  The text is even different
> between the Tag for Tunnel-Type and the Tag for Tunnel-Medium-Type, even
> though the interpretation is evidently supposed to be identical.  The Tag
> for other attributes is interpreted variously. In some cases, it is
> required, in others, it is not.
>   
> I suggest having both a uniform text and interpretation for the Tag field
> throughout all attributes.  I have heard the argument that this will break
> interoperability with previous versions of the draft.  IMHO,
> interoperability with previous draft versions in not a desirable goal.
> One should not have to know the history of a draft to implement it, and
> all that matters is interoperability with the final published version. 
> 
> Here is a little table I have devised to show the inconsistencies with the
> current draft.  View in a fixed font for best results:
> 
> Key:  
> --Req?  Is tag field required for this attribute?
> 
> --Range  What is the allowed range of values for the tag field for this
> attribute?  Include all possible byte values that may legally appear in
> this position.
> 
> --Zero?  Is a zero value allowed for this attribute?
> 
> 
> Attribute        Req? Range      Zero? Comments
> ---------        ---- -----      ----- --------
> -Type            Yes  0x00-0x1F  Yes   (1)
> -Medium-type     Yes  0x00-0x1F  Yes   (1)
> -Client-Endpoint No   0x01-0xFF  No    (2)
> -Server-Endpoint No   0x01-0xFF  No    (2)
> -password        Yes  0x01-0x1F  No    (3)
> -pr-group-id     No   0x01-0xFF  No    (2) 
> -assignment-id   No   0x01-0xFF  No    (2)
> -preference      yes  0x01-0x1F  Yes   (4)
> 
> 
> (1) Even though the interpretation of Tag for these two attribute types is
> identical, the text describing them is not identical.  For some reason,
> the Tag description Tunnel-Medium-Type explicitly calls zero "0x0000",
> while Tag for Tunnel-Type does not.  Actually, 0x0000 must be wrong,
> because there's not enough room in a Tag field for 0x0000, just for 0x00.
> 
> (2) If value > 0x1F, behave as if tag was omitted, and interpret the value
> here as the first byte of the next field.
> 
> (3) "Ignore" values > 0x1F.  It is not clear what ignore means - ignore
> the whole attribute, or just the field?
> 
> (4) Behavior is undefined for values >0x1F.  Behavior is contradictory for
> the value 0x00.  0x01-0x1F is given as the explicit range of valid values,
> but the text immediately following says that 0x00 is also a valid value.
> So it is unclear whether a 0x00 is a valid value.  What a receiver is
> supposed to do if it receives a value > 0x1F is undefined.
> 
> ------------------------------------------------------
> 
> Here is my suggestion on how to fix this mess:
> 
> Have a uniform interpretation and text for the Tag field, for all
> attributes, as follows.  The Tag field is always required, never
> interpreted as part of the next field, and has defined behavior for all
> possible values.
> 
>    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 Tags used to group attributes are 0x01 through 0x1F,
>    inclusive. If the Tag field is not used to group attributes, it MUST be
>    zero (0x00).  Any other value found in the Tag field SHOULD be treated
> as
>    a value of zero by the receiver.
> 
> + Mark Anthony Beadles +  UUNET Product Development  + 
> +  [email-masked]   + http://networking.us.uu.net +
> +  Voice 614.723.1941  +       Fax 614.723.8407      +
> 
> 
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.