Subject: (radius) draft-ietf-radius-tunnel-auth-06.txt feedback & question

From: Leonard Cuff <[email-masked]>
Date: Tue, 3 Nov 1998 15:23:08 -0800 (PST)

Glen,

(1)  (Nit)  Section 1 says the document is filed as
draft-ietf-radius-tunnel-auth-05.txt,
(instead of -06).  You should change it to -06 for the next draft :-) :-)

(2)  (Nit)  Section 5.2, the paragraph talking about tags specifies that an
unused tag
must be zero (0x0000) but since the tag is only an octet, zero is (0x00).

(3)  As I interpret it, Section 5 says that the Tag field SHOULD NOT be used
used unless 
multiple instances of an attribute occur.  Is there a strong reason why a
single set of 
attributes could not tagged???

As a frame of reference I'm mostly focussed on proxy environments, where a proxy
may send a set of tunnel attributes, and another set of attributes might
already exist (in 
which case they needed to be deleted or re-written with tags prior to
proxying), so it simplifies
the implementation a hair if we can tag a set even if it's the only set in
the packet.

(4)  We're currently doing some interoperability testing with another vendor
who sends an "untagged"
Tunnel-Client-Endpoint (and Tunnel-Server-Endpoint), but has put a zero in
the tag field.  Our \implementation doesn't currently support this.  My
reading of Sections 5.3 and 5.4
is that this is not a valid.  To wit the Tag paragraph says "Valid values
for this field are
0x01 through 0x1F", but I have some sympathy for the other vendor, as the
diagram doesn't have
any indication that the tag field is optional, and when the tag field is
unused for other attributes 
(the non-string attributes) it is "unused" by setting it to zero.

I suggest that this be clarified in three places:  

(a)  The first paragraph of Section 5 could have some added text as follows:  
Note: "unused" means set to zero for some attributes, and entirely omitted
for other attributes.  

(b) the packet format diagram for these attributes should have some
indication that this tag is optional.
Perhaps nothing more than:

    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  (optional)|    String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

(c)  The text for the Tag attribute should say the tag field is optional,
and MUST BE omitted
if unused.  Yes, that's what's implied by the existing phrase  "otherwise,
it  SHOULD be interpreted as 
the first byte of the following String field", but this wasn't enough for at
least one implementor....

...for that matter, SHOULD doesn't seem strong enough in the just-cited
text......

Regards,

Leonard

-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 3 Nov 1998 16:38:24 -0800

>(instead of -06).  You should change it to -06 for the next draft :-) :-)

Whoops!

>must be zero (0x0000) but since the tag is only an octet, zero is (0x00).

Whoops! redux

>attributes could not tagged???

I suppose not - outside of the waste of a byte.  Not finding another set of
tagged attributes might confuse some servers...

>Perhaps nothing more than:

Strictly speaking, the Tag _isn't_ optional -- it just becomes "invisible"
if it's not in use.

>...for that matter, SHOULD doesn't seem strong enough in the just-cited

I can agree w/that, I think.

-