Subject: (radius) WG LAST CALL on L2TP RADIUS Drafts

From: Carl Rigney <[email-masked]>
Date: Wed, 6 Jan 1999 22:55:45 -0800 (PST)

This is the Working Group last call for the 3 RADIUS L2TP drafts before
sending them to IETF Last Call before advancing them to Proposed
Standard.  If you have any comments on them please send them to the authors
or the [email-masked] mailing list BEFORE January 22nd.
The RFC Editor may need to hang on to them until the L2TP working group's
drafts get RFC numbers as well so that the appropriate reference can be inserted,
but we might as well get them into the queue.  If L2TP changes substantially
we can always update and re-issue these.

http://www.ietf.org/internet-drafts/draft-ietf-radius-tunnel-imp-04.txt
http://www.ietf.org/internet-drafts/draft-ietf-radius-tunnel-auth-06.txt
http://www.ietf.org/internet-drafts/draft-ietf-radius-tunnel-acct-02.txt

--
Carl Rigney
RADIUS WG Chair
[email-masked]
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 15 Jan 1999 14:03:17 +0100

I'll reiterate what I told Glen in private mail:

A worry has been expressed to me that this set of drafts describe how to
set up a tunnel between a corporate firewall and a NAS box.
This would make the NAS box part of the trust boundary of the corporation,
and expose the NAS box operator to heavy liability and operational problems.

Some possible responses:

- The protocol does not require the endpoints of a tunnel to be in any
  particular place. The tunnel endpoint could be at the connected system,
  where it ought to be.

  Counter: How would the NAS box tell the connected system to set up a
           tunnel, if there is no such function in its connection protocol?
           Anyway, if that's a recommended mode, it should be documented.

- Tunnels aren't just for security. There might be other reasons to tunnel.
  
  Counter: But if you use tunnels for security, you should be warned that
           you can't use this feature.

I certainly don't understand this protocol well enough to see what's possible,
what's reasonable and what's obvious.

But I know that I didn't feel like I understood the problem and the Right
Way to solve it after reading the documents.

And that I don't like.

                         Harald A

-- 
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

-

---

From: Thomas Kinnen <[email-masked]>
Date: Tue, 19 Jan 1999 11:28:46 -0800

> or the [email-masked] mailing list BEFORE January 22nd.

One thing in the drafts that I'm not to overlly thrilled by is the fact many
of the attrubtes are using a different structure then the existing string and
int types to add this 'tag' collumn in.  This will cause server vendors to
have to hard code in special code points for these attributes.  I would rather
see a new data type called Tstring or Tint for taged String or taged int. 

---
Thomas C Kinnen - <[email-masked]> <[email-masked]>
"All of the opinions stated above are my own and not my employer's,
unless they were given to me by my employer"
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: Aydin Edguer <[email-masked]>
Date: Tue, 19 Jan 1999 15:06:13 -0500 (EST)

> One thing in the drafts that I'm not to overlly thrilled by
> is the fact many of the attrubutes are using a different structure
> then the existing string and int types to add this 'tag' collumn in.

Tags are definitely a new thing, but they have been in the drafts since
draft-01 (they were not in draft-00) [24 March 1997].

The format stabilized around draft-03 and has not really changed.

> This will cause server vendors to have to hard code in special code
> points for these attributes.  I would rather see a new data type
> called Tstring or Tint for taged String or taged int. 

It will definitely adds work for the RADIUS servers.  The approach
I would recommend, is the one that Merit adopted, which is to add
"TAGGED" as additional characteristic of attributes, along with
"SALTED" (for new encrypted attributes).  This allows other attributes
to easily use the new format in a generic way.

This way the basic types do not change.
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 19 Jan 1999 16:08:36 -0500

> The approach I would recommend, is the one that Merit adopted, which
> is to add "TAGGED" as additional characteristic of attributes, along
> with "SALTED" (for new encrypted attributes).  This allows other
> attributes to easily use the new format in a generic way.
>

  Maybe I'm missing something.  The TAGGED attributes are NOT
'tag + integer' and 'tag + string', but '4-octet integer with the
first octet as (perhaps) a tag', and 'string with the first octet as
(perhaps) a tag'.

  The 'perhaps' bit causes much more coding to properly support tagged
integers and strings, IMHO.

  From draft-ietf-radius-tunnel-auth-06.txt:

 (for a 'string' attribute)
      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 value of the Tag field is less than or equal to
      0x1F, it SHOULD be interpreted as indicating which tunnel (of sev-
      eral alternatives) this attribute pertains; otherwise,  it  SHOULD
      be interpreted as the first byte of the following String field.

  i.e. Ambiguous in definition (is it a string octet or a tag octet?)
and in implementation (maybe we do that, maybe we don't.)  I can see
interoperability problems resulting from these abiguities.

  The tagged attributes are, then, NEW basic types.  If the spec said
'tag PLUS integer/string', then for the 'tagged integer' type, I would
expect to see:

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

   and not expect to see 'tag (perhaps), followed by 3 octet network
byte order integer'

   4 octet network-byte-order integers are well understood.  3 octet
ones are not, and require special-case code.  Having the first octet
of a string as 'perhaps' a tag also requires special-case code.

  Is it really necessary to save that extra byte of space in the
packet for each tagged attribute?  Is there a benefit that the current
spec has, which trivializes my worries about the format?

  Alan DeKok.
-

---

From: Thomas Kinnen <[email-masked]>
Date: Tue, 19 Jan 1999 13:02:09 -0800

> integers and strings, IMHO.

Yep, That's why I would perfer to see a new basic data type that specifices
that there is a tag.  This would also allow the reuses of this data type as
new adttributes are added that require to be grouped together with out adding
additional special case coding.   

----

---

From: Aydin Edguer <[email-masked]>
Date: Tue, 19 Jan 1999 16:45:31 -0500 (EST)

>  Maybe I'm missing something.

I ...think... you may be missing something.  The field is the same
size as the normal data type.  The first octet in network byte order
is then masked off *by the receiver* to determine if a TAG was used
in the attribute.

This is to allow backwards compatibility - you can actually use tagged
attributes without modifying your RADIUS server using appropriate values.

For instance, to send an integer with "Tag 0x01, Value 0x10", you can
just send a Value 16777232 (dec).

> interoperability problems resulting from these abiguities.

It is always string a string attribute.  It may or may not be tagged.
You can unambiguously determine if there is a tag based upon the value
of the first octet.

The Tag is a *part* of the traditional data type.  It is not external
to the data type.

> 'tag PLUS integer/string', then for the 'tagged integer' type, I would

This is the opposite of how I would feel.  *If* the Tagged attributes
were a new data type, then they would have a format like this, because
the Length would actually be different.  Because they share the same
length and thus can fit in the same format, they are not really new
basic types.

> of a string as 'perhaps' a tag also requires special-case code.

It is still a 4 octect network-byte-order.  The first octet is then
masked off to verify if a tag is present.

> Is it really necessary to save that extra byte of space in the packet
> for each tagged attribute?

It is to allow backwards compatibility.  It is actually very flexible
and allows you to use an unmodified server to send properly Tagged 
values.

> Is there a benefit that the current spec has, which trivializes my
> worries about the format?

For more on this, you can go back to the RADIUS-WG mailing list archives.
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.