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

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

Your suggestions still do not clear up the following issues.  Simple
clarification is not enough, the behavior prescribed by the draft is flawed:

In Tunnel-Type and Tunnel-Medium-Type:

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

In Tunnel-Password:

> (3) "Ignore" values > 0x1F.  It is not clear what ignore means - ignore
> the whole attribute, or just the field?

In Tunnel-Preference:

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

IMO, we MUST NOT design protocols that have values for which behavior is
undefined or contradictory.  We also MUST NOT use different text to describe
what is supposed to be the same functionality.  I think it's also a real bad
idea to bend these attributes to the breaking point just so we don't have to
change code in real old servers, but I may be outvoted on that one.

The thing is, RADIUS Client/Tunnel Initiator Vendors are going to have to
write new code NO MATTER WHAT to support this functionality. And old RADIUS
Servers are never going to support password ANYWAY. You could always do
something like:

One set of attributes where Tag is always required and explicit:
> Tunnel-Type            
> Tunnel-Medium-type     
> Tunnel-Client-Endpoint 
> Tunnel-Server-Endpoint 
> Tunnel-password        
> Tunnel-pr-group-id      
> Tunnel-assignment-id   
> Tunnel-preference  

One set of attributes (minus password) for old RADIUS servers, where there
is no Tag field at all:
> Compat-Tunnel-Type            
> Compat-Tunnel-Medium-type     
> Compat-Tunnel-Client-Endpoint 
> Compat-Tunnel-Server-Endpoint 
> Compat-Tunnel-pr-group-id      
> Compat-Tunnel-assignment-id   
> Compat-Tunnel-preference          

Old servers can then support the latter set, new servers can support the
former, and NAS's have to be prepared to accept either JUST AS THEY ARE WITH
THE CURRENT PROPOSAL.

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