Subject: Draft of extensions format

From: Alan DeKok <[email-masked]>
Date: Wed, 01 Sep 2010 16:24:20 +0200

Avi and I talked at the last IETF, and have had a number of follow-up
conversations since then.  I've just submitted the resulting document.

  At a high level, this document:

a) requests allocation of 6 "reserved" attributes

b) assigns 4 to a new format, which has one octet of "extended type"
   TYPE LENGTH Extended-Type Value...

c) assigns 2 to a new format which allows for more than 252 octets
   of data, using another octet for a "more" flag

d) defines a TLV data type, for TLV nesting as done in WiMAX and 3GPP2.

e) creates 6 VSA containers using the above formats

  This extends the RADIUS attribute type space by over 1500 possible
attributes.  It allows for a generic "long" attribute.  It allows for
better grouping than RFC 2868.  For most of the attributes, the new
format has only 1 octet of overhead over the current format.

  The document contains an analysis of how the new format will affect
existing systems.  It also contains a stub "guidelines" section, for how
attributes of the new format should be designed.

  Alan DeKok.

------
A new version of I-D, draft-dekok-radext-radius-extensions-00.txt has
been successfully submitted by Alan DeKok and posted to the IETF repository.

Filename:	 draft-dekok-radext-radius-extensions
Revision:	 00
Title:		 Remote Authentication Dial In User Service (RADIUS) Protocol
Extensions
Creation_date:	 2010-09-01
WG ID:		 Independent Submission
Number_of_pages: 23

Abstract:
The Remote Authentication Dial In User Service (RADIUS) protocol is
nearing exhaustion of its current 8-bit attribute type space.  In
addition, experience shows a growing need for complex grouping, along
with attributes which can carry more than 253 octets of data.  This
document defines changes to RADIUS which address all of the above
problems.

The IETF Secretariat.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Peter Deacon <[email-masked]>
Date: Wed, 1 Sep 2010 09:47:45 -0700 (Pacific Daylight Time)

>   of data, using another octet for a "more" flag

Conceptually I like the extensions.

We are already set to run out of attribute space once.  For that reason 
allocating additional space on the same order could possibly lead to the 
same problems in the future.

My recommendation is to use a single extensions attribute and make length 
two bytes.  Rob a couple of bits from the 16-bit length field for fragment 
and possibly presence of an extra flags byte.

Finally reserve the lower region that overlaps with the current standard 
attribute space so that there are no conflicts with attribute id 
references.  Thus sub attribute ID's would not be needed in this context.

regards,
Peter

---

From: Peter Deacon <[email-masked]>
Date: Wed, 1 Sep 2010 09:53:18 -0700 (Pacific Daylight Time)

> allocating additional space on the same order could possibly lead to the same 
> problems in the future.

> My recommendation is to use a single extensions attribute and make length two 
> bytes.  Rob a couple of bits from the 16-bit length field for fragment and 
> possibly presence of an extra flags byte.

I apologize..

s/length/type

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Wed, 01 Sep 2010 22:25:35 +0200

> Conceptually I like the extensions.

  Thanks.

> same problems in the future.

  We've taken 13 years to assign about ~140 attributes.  This works out
to ~11 attributes per year.  Even if we allocate attributes 4x as
quickly, (~45 per year), the ~1500 new attributes should allow for about
33 years of progress.  At 10x the historical rate, we will have ~14
years of progress.

  That calculation ignoring nested TLVs, which further extend the type
space.  And it's ignoring the possible 1500 new VSAs for each vendor.

> My recommendation is to use a single extensions attribute and make
> length two bytes.  Rob a couple of bits from the 16-bit length field for
> fragment and possibly presence of an extra flags byte.

  Do you expect the 1500 attributes to be exhausted within 5 years?

  Even if this did happen, there are ~50 unallocated attributes in the
"unassigned" and "reserved" spaces.  Allocating 40 of them to the new
type would allow for 10K new attributes.  This total is about the same
as you would get with a ~13 bit type space, and 3 bits of flags.

  To put it into perspective, there are about 5K attributes which have
been defined by major vendors and are in widespread use.  I just don't
see a need for *fast* allocation of 1000's of attributes.

> references.  Thus sub attribute ID's would not be needed in this context.

  That would permit "old" style attributes to be encapsulated in the
"new" style attributes.  (Even if it was forbidden, the encoding would
allow for it.)

  In contrast, our document solves the conflict by proposing a new
*naming* mechanism.  There is no conflict between "new" attribute "1",
and "old" attribute "1".  This is because the new attribute is defined
within the context of the encapsulation layer: the "old" attribute ID.

  i.e. The "old" number 241 uses the "new" format, and it can carry the
"new" attribute "1".  This attribute is referred to numerically as
"241.1", which makes it immediately distinct from "1", which is the old
User-Name attribute.

  There is no need to avoid conflicts with the "attribute id
references", because the naming system is such that conflicts are
impossible.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Wed, 1 Sep 2010 14:12:16 -0700 (Pacific Daylight Time)

>  Do you expect the 1500 attributes to be exhausted within 5 years?

I agree with you in that it is unlikely.  Personally I would be surprised 
if we ever run out of standard attributes.  It seems organizations are 
more likely to go the route of VSAs (DSL Forum, wimax, 3gpp..et al).  I'm 
not very good at predicting the future so I try not to.

> within the context of the encapsulation layer: the "old" attribute ID.

The underlying question for me: Is this just a solution in search of a 
problem?  With my recommendation the same underlying goal is met and the 
dot naming exercise is unnecessary.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Thu, 02 Sep 2010 08:08:51 +0200

Peter Deacon wrote:
> I agree with you in that it is unlikely.  Personally I would be
> surprised if we ever run out of standard attributes.

  The WG meeting looked into this at the last IETF.  The conclusion was
that at the current rate of allocation, we have 4-5 years.  Given that
it takes 4-5 years to publish a document, we need a solution now.

>  It seems
> organizations are more likely to go the route of VSAs (DSL Forum, wimax,
> 3gpp..et al).  I'm not very good at predicting the future so I try not to.

  Some vendors have started running out of VSA space.  Having a solution
would be useful *now*.

> dot naming exercise is unnecessary.

  The dot naming exercise *also* allows for naming and allocation of
nested TLVs.  Without it, a TLV "1" could be seen as being in conflict
with attribute "1".

  The document explains this, most notably in the "IANA Considerations"
section.

  Your solution has a problem (conflict) that this solution does not
have.  It provides for allocation of ~8K attributes which you say here
isn't necessary.  And even if it was necessary, our proposal can address
that problem, too.  If your solution allows for TLVs, a "dot naming"
scheme is *also* necessary for it, too.

  On the "plus" side, I don't see a lot of differences between the two
solutions.  On the "negative" side, there are issues with your proposal
that our document does not have.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Thu, 2 Sep 2010 01:57:06 -0700 (Pacific Daylight Time)

> have.  It provides for allocation of ~8K attributes which you say here

I think this boils down to my advocating for a flat model where each item 
stands alone while the draft is advocating a hierarchical model where each 
items identity is strictly dependent on its parent.

When draft says TBD.1 it means attribute 'TBD.1'

When I say TBD.1 it means User-Name (Type 1) encoded in whatever TBD is. 
(TLV, Extension..etc)

For example lets say I have two TLVs (Containers) labeled Input and 
Output.

Input
- Octets
- Packets

Output
- Octets
- Packets

Under the drafts scheme the attributes defined would be:

Input
Output
Input.Octets
Input.Packets
Output.Octets
Output.Packets

Under my recommendation the attribute picture is flattened:

Input (TLV Attribute)
Output (TLV Attribute)
Octets (Attribute)
Packets (Attribute)

On the wire the basic structure of the packet is the same with octets and 
packet data encapsulated within input and output TLVs.

This boils down to a classic flat vs hierarchical schema argument.

As I see it the benefits of my recommendation are:

1. More flexibility.  Existing attributes that were never labeled as 
groupable can be grouped.  For example I could create a generic TLV 
container labeled 'suspect' containing all attributes that an intermediate 
proxy does not like.

2. "Like" attributes within TLVs can be reused.  In the example above 
Octets and Packets need only be defined once and then apply to Input, 
Output and maybe a future "Combined" TLV container.  To some extent this 
is just a schema/definition argument.

3. The standard VSA space can be extended with less complexity/wholesale 
change to existing infrastructure as every attribute definition stands 
alone and is therefore fully compatible with the current model.

I think its important to recognize there are two separate issues: 
Extension of standard attribute space and introduction of TLV (Container). 
The two address separate concerns.  It may not be in everyones best 
interest to marry them.

Disadvantages of my recommendation:

1. What is allowed in a group may or may not simply be defined by 
declaration in a dictionary.  Need a concept to declare constraints (LDAP 
"object classes").  I would argue you would need this anyway if there was 
interest in for example declaring minimum required sub attributes for a 
specific TLV.

2. There is a strange aspect in that the additional space has to be 
"bootstrapped".  Either hardwired or configuration to say standard space
> 2^8 goes to a TBD extension attribute along the same lines as
Vendor-Specific (26) in the implementation.

Anyway after looking over the draft again I have some (un)related 
comments:

I think fragmentation support for 'jumbo' attribute values is a good thing 
however with the draft there does not seem to be a way to do both TLV 
grouping and attributes with large payloads at the same time.  IIRC wimax 
VSAs support this.  Could perhaps just get rid of TLV format and reuse the 
extended type as TLV?

In RADIUS everything is a "TLV" .. If it were labeled Container TLV or 
something similar to disambiguate the data types actual intended use it 
would be less confusing (to me).

2.4.3

"to the number of the encapsulating
    attribute ("241.1"), to yeild "245.1.1".  "
                            ^^^^^ should be yield

                ^^^ should be 245?

> scheme is *also* necessary for it, too.

To the extent relationship between TLVs and attributes need to be defined 
your correct.  At the same time however it's not required when TLVs are 
not used.  In my view an important difference.

> that our document does not have.

I would think the wire format is similar either way.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Thu, 02 Sep 2010 14:42:23 +0200

Peter Deacon wrote:
> I think this boils down to my advocating for a flat model where each
> item stands alone while the draft is advocating a hierarchical model
> where each items identity is strictly dependent on its parent.

  Pretty much, yes.  That's a result of adding the TLV format, which is
breaks the flat model wide open.

> When draft says TBD.1 it means attribute 'TBD.1'

  Yes.

> When I say TBD.1 it means User-Name (Type 1) encoded in whatever TBD is.

  That's the issue.

> Under the drafts scheme the attributes defined would be:

  Yes.  It's not optimal, but it's been proven to work in 3GPP2 and WiMAX.

> Under my recommendation the attribute picture is flattened:

  How do you encode the TLV's?  As 16 bit quantities?  They must be,
because otherwise all 256 attributes would be already allocated.

  And this suggestion is largely the Diameter Group attribute.  If we go
down that path, it would be preferable to use a method compatible with
Diameter, rather than one which is slightly different.

> This boils down to a classic flat vs hierarchical schema argument.

  Yes.

> container labeled 'suspect' containing all attributes that an
> intermediate proxy does not like.

  What is the use-case?

  And we've had that discussion already on this list.  The consensus was
that there are just too many uncertainties and confusions with that
approach.  What does it mean when a User-Name is grouped inside of a new
TLV?  How do existing proxies deal with that data?  Do you put the
User-Name outside of the TLV, and also inside?

  These issues *must* be answered before your proposal can move forward.

> is just a schema/definition argument.

  That is an admirable goal, and one which the document does not meet.
Existing information (3GPP2, WiMAX, vendors, etc.) shows that the re-use
isn't much of a problem, as it has been done.

  Again, what is the use-case for this?

> alone and is therefore fully compatible with the current model.

  What is the use-case?  How is it "less complex"?  How is encapsulating
User-Name in a TLV "fully compatible" with current RADIUS?

  The answer to the last question is easy: it isn't.

> Extension of standard attribute space and introduction of TLV
> (Container). The two address separate concerns.  It may not be in
> everyones best interest to marry them.

  The TLV format as defined in the document extends the standard
attribute space.

> declaration in a dictionary.  Need a concept to declare constraints
> (LDAP "object classes").  I would argue you would need this anyway if
> there was interest in for example declaring minimum required sub
> attributes for a specific TLV.
> 

  Please propose something *concrete*, with use-cases.

> Anyway after looking over the draft again I have some (un)related comments:
> 
> I think fragmentation support for 'jumbo' attribute values is a good
> thing however with the draft there does not seem to be a way to do both
> TLV grouping and attributes with large payloads at the same time.  IIRC
> wimax VSAs support this.  Could perhaps just get rid of TLV format and
> reuse the extended type as TLV?

  The discussions Avi and & had were that we couldn't see a use-case for
TLVs needing more than 253 octets of data.  The WiMAX VSAs do *not*
support TLVs having large payloads.

> would be less confusing (to me).

  RFC 2865 defines Attributes.  The acronym TLV does not appear in any
standards-track RADIUYS document.

>    attribute ("241.1"), to yeild "245.1.1".  "

  Yes, thanks.

> To the extent relationship between TLVs and attributes need to be
> defined your correct.  At the same time however it's not required when
> TLVs are not used.  In my view an important difference.

  It's semantics.  Calling a new attribute 1234 or 241.1 makes little
difference.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Thu, 2 Sep 2010 10:13:41 -0700 (Pacific Daylight Time)

> breaks the flat model wide open.

There are many ways of representing the same structured data.  Purely 
hierarchical approach advocated in the draft suffers from the multiple 
inheritance problem.

> because otherwise all 256 attributes would be already allocated.

Yes, my proposal is the type field be a 16-bit or 14-bit field to save a 
byte on fragment and extra flag bits.

> Diameter, rather than one which is slightly different.

My thinking is the definition is more important than the wire format. 
The wire format is out of sight out, out of mind.  The universally 
standardized definition of attributes is what I am most concerned with. 
If it looks like diameter so be it..

>  These issues *must* be answered before your proposal can move forward.

This was just a hypothetical to provide an example usage of which I have an 
infinite supply so if you need more just ask and I'll rattle off more use 
cases until everyone is satisfied.

In this case its my attribute I define what the group means.. My TLV 
attribute is labeled Proxy-Suspects and it means everything in the group is 
an attribute an intermediate proxy server in the chain did not "like".

Its proxied by servers who do not support/understand it the same as any 
other unknown or specifically unsupported attribute would be per this 
draft and other RFCs.

Since the TLV is an attribute type in itself the system must understand 
what the type means before it can do anything with the data contained 
within it.  The User-Name attribute inside the TLV is characterized by its 
container and semantics associated with the definition of the type.

Example...

TLV - Proxy-Suspects
- TLV Proxy-Suspect-Attribute
-	User-Name = Rumpelstiltskin
 	Proxy-Suspect-Reason = Too-Big
- TLV Proxy-Suspect-Attribute
 	Framed-IP-Address = 127.0.0.1
 	Proxy-Suspect-Reason = Policy-Reject

>  Again, what is the use-case for this?

I think fundamentally there is a difference in the efforts you cite have a 
finite scope to a specific problem domain.  The WG is defining a broadly 
scoped attribute that applies to many disparate problem domains and so 
what is workable in these cases may not be ideal in the general case.

> User-Name in a TLV "fully compatible" with current RADIUS?

The issue is the attributes are defined based on their parents and don't 
standalone and so don't fit with the current flat model of defining 
attributes with integer values as self-contained entities.  Subgroups 
require implementation infrastructure change to support.

Again assume TLV grouping is *NOT* used in this case.  The drafts scheme 
has a dual use to extend the standard space AND support TLVs.  The problem 
is it should in my opinion be possible for a client to use use extended 
attributes without having to support TLVs and the sub attribute encoding 
scheme that go with them.

My recommendation is easier because each attribute retains a unique 
integer identity as is current practice for all standard attributes and 
most VSAs and thus easier for client vendors to implement extended 
attributes within their existing systems if they do not also have a need 
to support TLVs.

>  Please propose something *concrete*, with use-cases.

In terms of definition of attributes RADIUS is traditionally very loosely 
structured.  Attributes you don't understand can be tolerated even tho 
there is no way to communicate the information attribute x was ignored.

Subsequently new features such as Disconnect/CoA enforced a more strict 
interpretation in which unknown attributes mandate a NAK response by the 
NAS.

Loose vs strict structure is a subjective space and I can cite an example 
that would lean in either direction.

My suggestion WRT definition is to always define the minimal requirements 
in terms of sub-attributes for the use of any TLV and the possible 
sub-attributes whenever a TLV is defined in an RFC.

In terms of adherence only Recommend they are followed and give clients or 
servers the option of rejecting TLVs if the constraints are not met. 
Ideally these semantics would be defined with the TLV attribute and can be 
stronger or weaker based on the semantics of the specific TLV.

> support TLVs having large payloads.

I double checked and I don't believe this is correct..  See:
http://www.juniper.net/techpubs/software/aaa_802/sbrc/sbrc70/sw-sbrc-admin/html/WiMAX_Overview6.html

I have found other material that explicitly say the continuation flag may 
be used specifically with WiMax TLVs allowing up to 4k or so TLVs.

In any event this statement seems a little confusing to me.  On one hand 
you introduce a container that supports fragments but on the other hand 
say that there is no use case in TLVs supporting fragments.

In terms of a use case my Proxy-Suspects TLV would work here as well as it 
needs to potentially be larger than 2^8 for cases where the proxy server 
does not like multiple attributes.

> standards-track RADIUYS document.

TLV is universally understood to mean Type-Length-Value which all RADIUS 
attributes are.  This is the source of my confusion.

>  It's semantics.  Calling a new attribute 1234 or 241.1 makes little

So can we call them 1234 or maybe both? :)

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Thu, 02 Sep 2010 23:18:19 +0200

Peter Deacon wrote:
> The wire format is out of sight out, out of mind.

  The wire format has a strong dependency on the definition.  They
cannot be treated independently.

>  The universally

  The document defines what it means by attributes.  It explains the
difference between the new format and the traditional format.  It
explains how the new attributes should be interpreted, and how they can
be handled in traditional systems.

> This was just a hypothetical to provide an example usage of which I have
> an infinite supply so if you need more just ask and I'll rattle off more
> use cases until everyone is satisfied.

  I would suggest writing a document with a proposal and examples, as we
have done.  Right now, this conversation isn't making much progress.
Nearly every subject (requirements, wire format, examples) has been
vaguely defined, and has required repeated questions asking "what do you
mean?"

  I'm sorry, but we put the time and effort into creating a draft
explaining exactly what we mean.  I would prefer to discuss that
document rather than to help you debug and design your proposal.

> I think fundamentally there is a difference in the efforts you cite have
> a finite scope to a specific problem domain.  The WG is defining a
> broadly scoped attribute that applies to many disparate problem domains
> and so what is workable in these cases may not be ideal in the general
> case.

  That is so vague as to be unanswerable.

> require implementation infrastructure change to support.

  I presume at this point that all major RADIUS servers support 3GPP2
and WiMAX.  This means that they have already implemented TLVs as
proposed in the document.

  i.e. the TLVs in the document are *not* new to RADIUS server
implementations.

> has a dual use to extend the standard space AND support TLVs.  The
> problem is it should in my opinion be possible for a client to use use
> extended attributes without having to support TLVs and the sub attribute
> encoding scheme that go with them.

  This is a specious argument.  RADIUS clients implement the features
they need.  If they don't need EAP, they don't implement it.  The
document changes nothing of this behavior.

> attributes within their existing systems if they do not also have a need

  You're confusing the implementation data structures and the names in
the standards.  The document makes no requirements (or assumptions)
about internal implementation data structures.

> In terms of definition of attributes RADIUS is traditionally very
> loosely structured.  Attributes you don't understand can be tolerated
> even tho there is no way to communicate the information attribute x was
> ignored.

  The document does not change that behavior.

> In terms of adherence only Recommend they are followed and give clients
> or servers the option of rejecting TLVs if the constraints are not met.

  The use-case is... ?

> http://www.juniper.net/techpubs/software/aaa_802/sbrc/sbrc70/sw-sbrc-admin/html/WiMAX_Overview6.html

  You are not correct.  I suggest reading the WiMAX specifications.

> I have found other material that explicitly say the continuation flag
> may be used specifically with WiMax TLVs allowing up to 4k or so TLVs.

  No.  There may be up to 4K of TLV's in a WiMAX VSA.  But each TLV can
only carry 253 octets of data.  The hint should be that the
"continuation" flag is *only* at the VSA layer, and not inside of each TLV.

> say that there is no use case in TLVs supporting fragments.

  I suggest reading the use-cases and examples again.  The document
explains this, and I have explained it here.

> In terms of a use case my Proxy-Suspects TLV would work here as well as
> it needs to potentially be larger than 2^8 for cases where the proxy
> server does not like multiple attributes.

  That presents a solution.  I still have no idea what the problem is.

> attributes are.  This is the source of my confusion.

  The standards are written to be consistent, without referring to
unwritten "universal understanding".  There are many things that are
"understood" in RADIUS but which are unwritten, and therefore not
standardized.  See this mailing list archive for many examples.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Thu, 2 Sep 2010 16:07:41 -0700 (Pacific Daylight Time)

> document rather than to help you debug and design your proposal.

I am suggesting what I believe to be a small change to make the 
existing draft better and more likely to be implemented in the wild.

- 16-bit Type field
- All attributes (Including TLVs and sub-attributes) have distinct 
integer identities.

> proposed in the document.

In the grand scheme of things RADIUS servers are trivial components.  I'm 
more concerned about all the client vendors and management infrastructure.

I think requiring sub-encoding scheme for extension attributes to access 
ordinary *UNGROUPED* attributes added at some point in the future 
represents a significant and unnecessary complexity and upgrade cost with 
little or no benefit.  Flipping a switch in a RADIUS server to support a 
new extension format is no problem.  However plumbing SNMP OIDs into 
existing infrastructure is a significant cost issue that is worth the 
attempt to avoid if possible.  For this reason I strongly oppose the draft 
in its current form.

My advice for solving the problem within the framework of your draft was 
to make type 16-bit and assign each attribute a unique integer identity.

If you look at what some are doing with the existing nested formats they 
write string parsing functions and stuff them into opaque strings that are 
then processed by the *RADIUS server* decoded and sent over the wire. 
Not exactly the shining example of widespread support of TLVs and not 
something I care to see be repeated for standard attributes as well.

> "continuation" flag is *only* at the VSA layer, and not inside of each TLV.

This is an example of why labeling the container TLV simply 'TLV' can cause 
misunderstandings and confusion.

In your draft TLV is actually the same thing as Wimax VSA.

When I say TLV is limited to 2^8.. I essentially mean the container 
grouping object (TLV) which is the same as Wimax VSA.  The Wimax VSA as 
you note supports fragmentation.

So I still believe I am correct in that TLV in your draft does not provide 
the same fragmentation options as the wimax implementation because the 
entire container is limited to 2^8 while wimax is not.

> standardized.  See this mailing list archive for many examples.

TLVs are used in more wire protocols than I can count.  When you say TLV I 
think attribute.. I don't assign the explicit use WRT containment / 
encapsulation with the description.  Container TLV. Envelope TLV... some 
qualifier to explain its use I think would be helpful to people with 
limited brain cells like myself but at the end of the day its a subjective 
assessment.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Fri, 03 Sep 2010 10:27:16 +0200

Peter Deacon wrote:
> I am suggesting what I believe to be a small change to make the existing
> draft better and more likely to be implemented in the wild.
> 
> - 16-bit Type field

  We had discussed this option, and decided to propose something else.

>  Flipping a switch in a RADIUS server to
> support a new extension format is no problem.  However plumbing SNMP
> OIDs into existing infrastructure is a significant cost issue that is
> worth the attempt to avoid if possible.  For this reason I strongly
> oppose the draft in its current form.

  See git.freeradius.org.  WiMAX VSAs with nested TLV support was added
in less than 1000 lines of code.  Additional internal API changes
(mostly automated changes with a Perl script) were another ~5000 lines
of code.

  i.e. the data shows that the cost is relatively small.

> write string parsing functions and stuff them into opaque strings that
> are then processed by the *RADIUS server* decoded and sent over the
> wire. Not exactly the shining example of widespread support of TLVs and
> not something I care to see be repeated for standard attributes as well.

  Implementation choices (and limitations) are outside of the scope of
the document.  While they need to be taken into account, the evidence
shows that the proposed format has been widely implemented, no matter
how ugly the method.

> In your draft TLV is actually the same thing as Wimax VSA.

  No.

> grouping object (TLV) which is the same as Wimax VSA.

  No.

> So I still believe I am correct in that TLV in your draft does not
> provide the same fragmentation options as the wimax implementation
> because the entire container is limited to 2^8 while wimax is not.

  No.

  You have not understood the document, or the WiMAX specs.

> TLVs are used in more wire protocols than I can count.  When you say TLV
> I think attribute.. I don't assign the explicit use WRT containment /
> limited brain cells like myself but at the end of the day its a
> subjective assessment.

  I welcome the suggestion of a better name.  Until that happens, there
is no pre-existing "TLV" data type in RADIUS. So adding one should not
cause any confusion.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Fri, 3 Sep 2010 07:59:46 -0700 (Pacific Daylight Time)

> (mostly automated changes with a Perl script) were another ~5000 lines

Even with the TLVs there is still a unique integer identity.. IE each 
wimax VSA itself is nnn not nn.nn.nn.  The sub-encodings can be addressed 
using the text encoding scheme that virtually everyone seems to be using 
so that in terms of referencing a WIMAX attribute externally its 
abstracted and treated in terms of external interfaces as an ordinary 
attribute and value string no different than User-Name.

Outside of the RADIUS server there are actually no changes necessary to 
reference attributes in the wimax case as I understand it.

As I mentioned the RADIUS server is just the tip of the infrastructure 
iceberg.  The argument you are making is akin to switching from IPv4 to 
IPv6.  Its easy to change software to listen on an IPv6 socket.. Its quite 
a different matter entirely to change all of the supporting infrastructure. 
The disruptive change is only tolerated because there exist no other 
reasonable option.

With this proposal for the first time in a down-to-earth practical sense 
what look like SNMP OIDs would be practically necessary to reference 
ordinary ungrouped attributes using the extension types added after the 
standard space was exhausted.  I think this can be problematic given that 
RADIUS is a mature technology if only in that its been around for longer 
than I will admit to remembering.

I'm all for new features and capabilities and the changes they imply. 
However we must be careful as history is riddled with evidence that 
unnecessary disruption is a hindrance to adoption.

Another approach I would favor is to acquire an enterprise number for 
future RADIUS attributes just treat them as VSAs and have this draft focus 
entirely on the grouping problem and sub-attributes.

>  i.e. the data shows that the cost is relatively small.

What data?  Is there a survey you can point me to?  Our own first hand 
knowledge paints a much different picture.  I would be interested in any 
data showing the cost to supporting infrastructure that you or anyone else 
has compiled on the subject.

>  You have not understood the document, or the WiMAX specs.

Can I ask how would you define a grouped VSA with multiple sub-attributes 
in your draft where the total length of the entire VSA exceeds the 1-byte 
type field?

Having manually coded Wimax VSAs I know how to do this in Wimax.  I just 
don't see a path to doing it in the current draft as written.

> is no pre-existing "TLV" data type in RADIUS. So adding one should not

Container TLV
Envelope TLV
Grouping TLV

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Fri, 03 Sep 2010 23:26:55 +0200

Peter Deacon wrote:
> wimax VSA itself is nnn not nn.nn.nn.

  Uh... the document proposes that each TLV have a unique integer
identity.  It's called the "type" field of the TLV.  This is the same as
WiMAX.  The "dotted number" scheme exists solely for IANA allocation.

>  The sub-encodings can be
> addressed using the text encoding scheme that virtually everyone seems
> to be using so that in terms of referencing a WIMAX attribute externally
> its abstracted and treated in terms of external interfaces as an
> ordinary attribute and value string no different than User-Name.

  i.e. referring to an attribute by name.  This is irrelevant to the
numbering scheme.

> standard space was exhausted.

  This argument is nonsensical.  I could make the same statement about
your proposal:

  A 16 bit attribute number?  The horror!  Everything in my
implementation assumes only 8bits!  Now I have to use *16 bit* integers
to deal with attributes?  You must be joking!  That's too much code!

> future RADIUS attributes just treat them as VSAs and have this draft
> focus entirely on the grouping problem and sub-attributes.

  Perhaps you missed the previous RADIUS extensions document, which
proposed exactly that.  The consensus was that the scheme was unworkable.

> What data?

  The data I posted, and which you deleted in order to claim that no
data exists.

>  Is there a survey you can point me to?  Our own first hand
> data showing the cost to supporting infrastructure that you or anyone
> else has compiled on the subject.

  If 6K lines of changes ("diff / patch" format) too high a cost for
you, then your programmers are too highly paid.

> Can I ask how would you define a grouped VSA with multiple
> sub-attributes in your draft where the total length of the entire VSA
> exceeds the 1-byte type field?

  For one, the question is meaningless.  What does it mean if "a VSA
length exceeds a type field"?

  If I interpret your question properly, the answer is to read the
document.  Section 7.3.  It doesn't matter if the data is a 251 octets
of "a", or 251 octets containing a sequence of TLVs.

  If that is still unclear, we can add more thoroughly worked examples
in a future rev of the doc.

> don't see a path to doing it in the current draft as written.

  For the life of me, I don't see why.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Fri, 3 Sep 2010 15:32:48 -0700 (Pacific Daylight Time)

> you, then your programmers are too highly paid.

I've tried multiple times to make a point that the RADIUS Server does not 
represent the entire constellation of everything effected by the decision.

It would be a mistake to use the effort of one aspect of any effected 
infrastructure to make a definitive judgment in EITHER direction.  It was 
in this context that I responded the way I did and in this context that my 
question remains unresolved.

For what its worth I did include your quote in my previous email it was 
separated by some of my commentary and most likely just overlooked.  I 
have no intention in playing games with anyone.

> length exceeds a type field"?

I'm going to use an example from an actual wimax attribute to reduce the 
chance of any dis-ambiguity.

For this example I will be using the wimax QoS-Descriptor:
Its structure is as follows:

1 byte -RADIUS  Type (26)
1 byte - RADIUS Length
4 bytes - Vendor ID
1 byte - Wimax type (29)
1 byte - Length
1 byte - Continuation
TLV1..
TLV2..
TLV3..
TLVn...

The continuation field in QoS-Descriptor allows me to make the attribute 
length larger than 255 by sending additional QoS-Descriptor attributes 
which are then concatenated together using the Continuation flag.

The result is that should the combined size of all TLVs within the 
QoS-Descriptor attribute in which no individual (Wimax-TLV) exceeds 251 
octets leads to overflowing of the single byte length field I can leverage 
the Continuation flag and send additional QoS-Descriptor attributes to 
extend the size of QoS-Descriptor.

I am attempting to understand the analogue of this mechanism as it 
relates to the draft.

> of "a", or 251 octets containing a sequence of TLVs.

I understand the extended type provides for fragmentation and reassembly 
in 7.3 but can it as I recommended earlier act as a container or can only 
the TLV data type?

2.1 and 2.2 (Extension header) say nothing of nesting.  2.3 and 2.3.1 
(TLV header) discuss using TLV for nesting.  The TLV header length is 
limited to a single byte.

If TLV type is only able to support nesting then in my Qos-Descriptor 
problem above I don't know how to define a QoS-Descriptor larger than what 
the 1-byte length field is able to hold.  This is the source of my 
confusion/question.

regards,
Peter

---

From: Peter Deacon <[email-masked]>
Date: Fri, 3 Sep 2010 18:00:43 -0700 (Pacific Daylight Time)

> Its structure is as follows:

Please disregard, I get it now.  This is all essentially describing wimax 
and works the same way and I can do the same thing.

For some reason I kept getting hung up on the meaning of the type field in 
the container which is my fault.  I came back to understand something I 
knew implicitly but didn't register for some reason:

Every time I look at the TLV description all I see is "nesting" 
"encapsulation" and "container" as in attributes within attributes never 
attributes NEXT to attributes and it wasn't clear to me thats what was 
being described. Its my fault.

>From 2.3.1

"That is, the "container" TLV-Length field MUST be exactly two (2)
    more than the sum of the "contained" TLV-Length fields."

If the container is not a TLV itself but instead an Extension attribute 
then there is no containing TLV-Length field actually present on the 
wire.

The length field in this case is the extensions length field which is an 
extension header representing a TLV value.

I just have to switch between "wire view" and "logical view" to keep 
things straight :(

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Sat, 04 Sep 2010 08:15:09 +0200

Peter Deacon wrote:
> I've tried multiple times to make a point that the RADIUS Server does
> not represent the entire constellation of everything effected by the
> decision.

  The code stats I quoted were from a library which implements RADIUS
for a server *or* client.  The API doesn't even need numbers.  Client
code can use attribute names nearly exclusively.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 04 Sep 2010 08:20:09 +0200

Peter Deacon wrote:
> Please disregard, I get it now.  This is all essentially describing
> wimax and works the same way and I can do the same thing.

  Yes.

> being described. Its my fault.

  Section 7.4 had an example of concatenated TLVs in an attribute.

> then there is no containing TLV-Length field actually present on the wire.

  Yes.

> extension header representing a TLV value.

  It defines an attribute which contains TLVs.  So we have two
containers for TLVs: the new format attributes, and TLVs themselves.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Mon, 6 Sep 2010 15:51:34 -0700 (Pacific Daylight Time)

There seems to be a contradiction.

6.
* TLVs which will never need more than 247 octets of data MAY be allocated
     from 241.*, 242.*, 243.*, or 244.*.

8.3
  Attributes of type
    "tlv" MUST NOT be assigned from the type spaces 241.*, 242.*, 243.*,
    or 244.*.

--
8.2.

The type tree does not provide guidance WRT how to form a vendor specific 
identifier.  With the 8-bit field restriction there does not seem to be a 
possible way that it could be used to label VSAs using extension 
attributes.

regards,
Peter

---

From: Peter Deacon <[email-masked]>
Date: Mon, 6 Sep 2010 16:19:09 -0700 (Pacific Daylight Time)

On Mon, 6 Sep 2010, Peter Deacon wrote:

> possible way that it could be used to label VSAs using extension attributes.

I was looking for a globally unique reference but I don't think this was 
the intention.. It would be kind of nice to have one identifier that would 
fully describe the attribute.

Perhaps consider carving an exception to 8-bit integers for VSAs spaces 
that are allowed to have their own vendor types so the naming scheme would 
work for existing VSAs with 16-bit types.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Tue, 07 Sep 2010 01:53:32 +0200

Peter Deacon wrote:
>> The type tree does not provide guidance WRT how to form a vendor
>> specific identifier.  With the 8-bit field restriction there does not
>> seem to be a possible way that it could be used to label VSAs using
>> extension attributes.

  The VSA space is managed completely by the vendor.  We can offer
suggestions on the docuemnt, but vendors are free to do whatever they want.

> the intention.. It would be kind of nice to have one identifier that
> would fully describe the attribute.

  Sure.  The same dotted-number notation could be used:

241.26.9.42
	241 - new attribute
	26  - VSA
	 9  - Cisco
	42  - some Cisco attribute.

> that are allowed to have their own vendor types so the naming scheme
> would work for existing VSAs with 16-bit types.

  There's no need to have an exception.  Vendors can do whatever they
want.  And the 8-bit integer limitation is *only* for IANA purposes.
The dotted number notation could be used for 16-bit VSAs, too:

26.4846.20106

	26    - VSA
	4846  - Lucent
	20106 - Modulation attribute

 Alan DeKok.