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

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

Forwarded at John's request.

+ Mark Anthony Beadles +  UUNET Product Development  + 
+  [email-masked]   + http://networking.us.uu.net +
+  Voice 614.723.1941  +       Fax 614.723.8407      +

-----Original Message-----
From: John Shriver [mailto:[email-masked]]
Sent: Wednesday, 02 June 1999 3:10 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Problem with tunnel-auth-06 and Tag

(By the way, I'm not on the ietf-radius list, if people think my
messages should be seen there, please forward them, as the SPAM
filtering won't let me post to it.)

As I look through this draft, I think someone has been too generous
with the SHOULD's.  There should be more MUST.  Some may be "if, then,
MUST".

   From: "Beadles, Mark A." <[email-masked]>
   To: "'John Shriver'" <[email-masked]>
   Cc: [email-masked], [email-masked], [email-masked],
	   [email-masked]
   Subject: RE: Problem with tunnel-auth-06 and Tag
   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.

Yeah, that's a typo.  Nobody's going to argue against fixing that.

   In Tunnel-Password:

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

My suggestion was that we should define a particular "not used"
value.  I don't know why it's not zero.  Maybe because this attribute
can be handled by a data-dictionary RADIUS server after all, but only
if it's non-zero.  Maybe we should define the "unused" value to be
0x69 ('i' in ASCII), since this is parameter 69.

   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.

If not tagged, the tag is 0x00, if tagged, the value is 0x0-0x1f.  If
the value is between 0x20 and 0xff, the attribute is ignored.  (It
does not belong to any of the 15 valid tag sets.)

IETF RFC's aren't a formal language.  But, if we explain the
motivation better, minor lapses in clarity are less likely to cause
problems in interpretation.

Clearly, we need to word things more clearly.  But I think we're stuck
with the fact that the intended protocol is somewhat wart-encrusted.

   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. 

An ancient data-dictionary RADIUS server can implement the
tunnel-password attribute, if it is willing to violate the MUST about
the salt being different each time.  This may be why 0 isn't the
canonical no-tag value for this attribute's Tag, the data-dictionary
servers may strip leading bytes of 0x00 from hex strings...

   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.

Umm, the RADIUS attribute numbering space is too damn small to get two
sets of values.  (This has been one of causes of much that has been
problematic about RADIUS standardization through the years.)

Some ISP's (obviously not UUNet) are VERY stubborn about sticking with
the ancient RADIUS server they are presently using, yet adding new
features.  That WAS a design goal of RADIUS.  (I was at the last
RADIUS BOF before the working group started.)  Also, this is why every
RAS vendor has to implement all the proprietary Ascend attributes,
standardized or not...

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

---

From: Carl Rigney <[email-masked]>
Date: Thu, 10 Jun 1999 21:46:33 -0700 (PDT)

> filtering won't let me post to it.)

It's not my intention that the spam filtering keep people who aren't on
the list from contributing.  I've added your address to the list of
'addresses not on the list who can mail to it anyway' so you can mail
to [email-masked] if you like.

--
Carl Rigney
[email-masked]
-