Subject: RE: Question regarding draft-ietf-radext-design-05.txt

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 25 Dec 2008 14:51:10 +0200

Hi David, 

I noticed that I did not reply to these messages. 

>> If you are truely serious about this issue then one should replicate 
>> the Diameter mechanisms where you can group AVPs arbitrarily 
>and where 
>> you have far more data types available.
>
>That proposal was made in one of the early extended attributes 
>drafts, and was rejected by the RADEXT WG.  WG consensus says 
>that approach is not acceptable or interesting to the WG.  So, 
>while technically you have a very valid suggestion, it does 
>not seem to gain traction in the RADEXT WG.
> 
>> I would like to discuss this statement a bit. It makes an assumption 
>> about the way how a RADIUS server works that might not be how it is 
>> always being used today. It indicates that a RADIUS server works 
>> roughly in the following way:
>> 
>> a) Receive attributes (e.g., attribute foobar)
>> b) Formulate a query based on the received attributes (e.g., select 
>> foobar from tables where user-id=X)
>> c) Return result from previous query
>> 
>> This ignores that there might be more complex processing going on in 
>> the RADIUS server, for example that other protocols need to get 
>> invoked to get the result (e.g., attributes Y require LDAP to fetch 
>> results from server X while other mechanisms may be consulted to 
>> obtain the necessary information related to attributes Z), 
>that there 
>> is some business logic that needs to be executed).
>
>The policy determination / enforcement mechanism of RADIUS 
>servers is solely a matter of implementation.  It might be 
>implemented by means of delegation / consultation with some 
>other service, via some other protocol.  Or it might not.

While this is indeed an aspect of implementation there seem to be aspects
that impact the larger topic of how extensibility is perceived to work. 

>
>> I would at least like to relax this statement a bit and acknowledge 
>> the fact that RADIUS servers are a bit more complex today than just 
>> boxes where one could have used SQL instead of the RADIUS protocol 
>> right away.
>
>I think readers likely know that.  The issue is whether 
>extensions to the RADIUS on-the-wire protocol should be 
>designed to accommodate the traditional, 
>data-dictionary-driven RADIUS server, or not.  I think what we 
>are saying is that, while complex RADIUS server 
>implementations exist, RADIUS protocol enhancements should not 
>be at the expense of the simple implementations.

I think it is not a question of simple or complex implementation. 
The main issue is what the specific customers want. AAA servers are used by
different clusters of customers (different types of enterprises, WLAN
hotspots, universities, ISPs, cellular operators, etc). These customers have
different needs but the guidelines do not acknowledge that there are
different classes of customers and hence the design guidelines are often
applied without considering these aspects. I believe I can say that because
I was a victim of "strictly applying" the guidelines as they are, despite
the examples provided in the document on EAP etc. 

> 
>> I think that policy languages in AAA servers are getting more common 
>> today.
>
>Perhaps.

Would be worth investigating what folks develop today. 

> 
>> Finally, I would like to mention that RADIUS documents sometimes 
>> specify RADIUS/Diameter compatibility in a wrong fashion.
>
>That's an issue we need to address, and get right.
>
>> For example, there are a number of RADIUS documents that 
>indicate that 
>> the corresponding Diameter AVPs have the M-bit set.
>> This cannot be possible since this would require a new Diameter 
>> application to be specified.
>
>Ah, the long-standing Diameter Application quagmire.  :-(
>
>> I am not even sure that it is always the right way to put such a 
>> section in a RADIUS document when they authors do not envision 
>> Diameter to be used in their specific environment.
>
>What do you suggest?

Based on the discussion we had at the AAA doctors meeting I will think about
some way forward. 

>
>> The following paragraph (and a lot of related text) is 
>related to the 
>> aspect of policy languages:
>> 
>>   However, some standard attributes do not follow this format.
>>   Attributes that use sub-fields instead of using a basic data 
>>   type are known as "complex attributes".  As described below, 
>>   the definition of complex attributes can lead to interoperability
>>   and deployment issues, so they need to be introduced with care.
>> 
>> It somewhat depends on how the policy language works and what you 
>> expect the policy language todo.
>
>Please elaborate...

The above statement makes the assumption that the parsing happens in some
C-alike language that was used to implement the entire RADIUS server. 
There are indeed issues when you touch this code. 

However, most AAA servers have an abstract language they use for handling of
msg processing. This language is typically not C and written in a way that
it does not lead to security issues. As such, even additional parsing that
has to be implemented it does not lead to any interoperability or security
problems. Furthermore, as I argued above, since RADIUS usage today requires
more interaction the same language is used for the other processing and when
new functionality is added new code is being added. 

>
>> If you also assume that the policy language is not only used to deal 
>> with the business logic but also with decoding and encoding of 
>> attribute content then one could deal with a number of 
>> interoperability and security issues with the choice of language.
>
>So, what you are suggesting is that the syntax and semantics 
>of RADIUS attributes are contextually dependent on some policy 
>decision that is opaque to the RADIUS client, proxies, etc?  I 
>think that's a Very Bad Idea (tm) and falls under the 
>recommendation against polymorphic attribute design. 

No, my argument is different. I believe that the argument that complex
attributes lead to interoperability, deployment and security issues as
stated in the draft is incorrect and can of course happen from certain
implementation choices. Most AAA server do not have these issues as they are
providing an abstract language for the developer for business logic,
parsing, msg handling, etc. 

>
>> Btw, has the draft been sent to other SDOs for review?
>
>No.  I don't think that individual drafts are noticed the IETF 
>New Work list (maybe I'm wrong) so it would only come to the 
>attention of other SDOs via the efforts of overlapping participants.

Maybe it would have been good to get some feedback from organizations that
typically mess around with RADIUS protocols. 

Ciao
Hannes

>
>
>--
>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/>
>

--
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: "D. B. Nelson" <[email-masked]>
Date: Fri, 26 Dec 2008 15:16:51 -0500

Hannes Tschofenig writes...

>> The issue is whether extensions to the RADIUS on-the-wire
>> protocol should be designed to accommodate the traditional,
> The main issue is what the specific customers want. AAA servers are
> used by different clusters of customers (different types of enterprises,
> WLAN hotspots, universities, ISPs, cellular operators, etc). These
> customers have different needs but the guidelines do not acknowledge
> that there are different classes of customers and hence the design
> guidelines are often applied without considering these aspects.

Certainly there are different classes of customers, different market
segments, different use cases, etc.  Does that mean that the protocol has to
differ to address each?  IMHO, that's not a formal "protocol" if it differs
depending on who's using it.  The syntax, i.e. message format, of a protocol
needs to be invariant; only the content of the messages should be variable.

> I believe I can say that because I was a victim of "strictly applying"
> the guidelines as they are, despite the examples provided in the document
> on EAP etc. 

This harkens back to the age old debate on whether RADIUS should provide
facilities to encode complex / structured data.  This debate is as old as
the RADEXT WG itself.   The current RADEXT WG consensus is that RADIUS
doesn't need extensive "structuring" facilities, and that the simple
"grouping" facilities, e.g. of the Extended Attributed draft, is sufficient.
Yes, this is far short of Diameter's capabilities, but we decided that
RADIUS should not be extended to maintain feature parity with Diameter.
Otherwise, why maintain both AAA protocols going forward.  :-)

> Based on the discussion we had at the AAA doctors meeting I will
> think about some way forward.

Thanks!

>> Please elaborate...
>
> The above statement makes the assumption that the parsing happens
> in some C-alike language that was used to implement the entire RADIUS 
> server. There are indeed issues when you touch this code.
>
> However, most AAA servers have an abstract language they use for
> handling of msg processing. This language is typically not C and 
> written in a way that it does not lead to security issues. As such,
> even additional parsing that has to be implemented it does not lead
> to any interoperability or security problems.

Hmmm...  "Most"?  The metric we have been using is the "data dictionary
driven" server, which is admittedly a fairly old implementation technique.
Such servers may have auxiliary "policy servers" that make more complex
decisions about authorization data than is possible with simple attribute
matching schemes or user group membership schemes.  The relevant point of
discussion, however, is the on-the-wire RADIUS message format.

RADIUS was designed to provision pretty simple things.  It originally
envisioned each attribute as having an "atomic" value, not some complex,
structured message.  I understand that AAA servers today attempt to
provision more complex things, and this is wherein the friction results.
Should RADIUS be extended, much as Diameter has, to support a more complex
and nuanced set of provisioning capabilities?  If so, then why do we need
Diameter? :-)

> No, my argument is different. I believe that the argument that
> complex attributes lead to interoperability, deployment and 
> security issues as stated in the draft is incorrect and can of
> course happen from certain implementation choices.

I see.  I guess I still disagree.  Yes, anything, no matter how complex,
convoluted and baroque can be made to interoperate with sufficient attention
to detail.  A pig, given sufficient thrust, can be made to fly.  :-)

> Most AAA server do not have these issues as they are providing an
> abstract language for the developer for business logic, parsing,
> msg handling, etc.

So, you're saying that today's AAA Servers are really Policy Servers?

I think that the basic issues here is that there is a disconnect between the
consensus position of the RADEXT WG (to keep things pretty simple) and need
you are describing to provide [near] capability parity with Diameter.

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 26 Dec 2008 14:17:51 -0800

"I think that the basic issues here is that there is a disconnect between
the
consensus position of the RADEXT WG (to keep things pretty simple) and need
you are describing to provide [near] capability parity with Diameter."

To quote the conclusions of the AAA protocol Evaluation team (RFC 3127) with

respect to the prospects for enhancing RADIUS so as to meet the AAA
requirements:

"  Radius++ is not considered acceptable as an AAA protocol.  There is a
   fairly substantial amount of engineering required to make it meet all
   requirements, and that engineering would most likely result in
   something close to the functionality of Diameter." 

Indeed, at various points with the RADEXT WG, questions have come up
relating
to adoption of one or more features of Diameter, and WG consensus has lined
up
with the RFC 3127 assessment:

1) during the discussion on Extended Attributes, the question arose
as to whether RADIUS should adopt the Diameter AVP format.  The WG
consensus was against this, and as a result only modest extensions
(for tagging and additional attribute space) were adopted. 

2) during the transport work, questions have arisen about the
suitability of the RFC 3539 watchdog timer and failover logic.  Again,
WG sentiment does not appear to support a strict port of the
Diameter functionality to RADIUS.  

So while it is possible (and potentially desirable) for RADEXT to
develop enhancements (such as Extended Attributes and RADSEC), this 
falls considerably short of providing the full functionality of 
Diameter.

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 27 Dec 2008 13:24:23 +0200

Hi David, 

>>> The issue is whether extensions to the RADIUS on-the-wire protocol 
>>> should be designed to accommodate the traditional, 
>>> data-dictionary-driven RADIUS server, or not.  I think what we are 
>>> saying is that, while complex RADIUS server implementations exist, 
>>> RADIUS protocol enhancements should not be at the expense of the 
>>> simple implementations.
>> 
>> used by different clusters of customers (different types of 
>> enterprises, WLAN hotspots, universities, ISPs, cellular operators, 
>> etc). These customers have different needs but the guidelines do not 
>> acknowledge that there are different classes of customers and hence 
>> the design guidelines are often applied without considering 
>these aspects.
>
>Certainly there are different classes of customers, different 
>market segments, different use cases, etc.  Does that mean 
>that the protocol has to differ to address each?

No. I am asking for considering the needs of some of the other usage
environments as well. 

>IMHO, that's 
>not a formal "protocol" if it differs depending on who's using 
>it.  The syntax, i.e. message format, of a protocol needs to 
>be invariant; only the content of the messages should be variable.

I am not sure I fully understand what you are saying. 

If you believe that different requirements may lead to different results
then you are essentially with me. 

Two examples: 

* EAP Channel Bindings: I mentioned that I was not able to find anyone in
the cellular industry that was interested in this. 
Does it mean that the work will not be done? No, because folks argue that in
the university space and enterprise environment it could be useful. 

* TLS and TCP for RADIUS: Most folks in the cellular space don't care about
this because they are specifying Diameter all over the place. 
As we have learned, folks working at the universities have different
constraints and needs (e.g., using software that is downloadable for free
from the Internet as a basis for their AAA deployment). As such, they like
this new work as it will solve their problem without switching to commercial
solutions or to switch to OpenDiameter etc. 

>> the guidelines as they are, despite the examples provided in the 
>> document on EAP etc.
>
>This harkens back to the age old debate on whether RADIUS 
>should provide facilities to encode complex / structured data. 
> This debate is as old as
>doesn't need extensive "structuring" facilities, and that the 
>simple "grouping" facilities, e.g. of the Extended Attributed 
>draft, is sufficient.

At least I am asking to capture these aspects in the draft as there are
really two types of complex attributes, namely those captured with the
RADIUS extended attributes draft and then more complex onces that can be
found also in the Diameter space. Reading through the draft one could easily
get the impression that that document now allows the Diameter AVP structure
to be easily supported, which is not true. 

>Yes, this is far short of Diameter's capabilities, but we 
>decided that RADIUS should not be extended to maintain feature 
>parity with Diameter.

It is fine not to align it 100% with Diameter. I just want the differences
to be documented in the document. 

>Otherwise, why maintain both AAA protocols going forward.  :-)

There are many reasons -- none of them have anything todo with technical
arguments. 

>> Based on the discussion we had at the AAA doctors meeting I 
>will think 
>> about some way forward.
>
>Thanks!
>
>>> Please elaborate...
>>
>> The above statement makes the assumption that the parsing happens in 
>> some C-alike language that was used to implement the entire RADIUS 
>> even additional parsing that has to be implemented it does 
>not lead to 
>> any interoperability or security problems.
>
>Hmmm...  "Most"?  The metric we have been using is the "data 
>dictionary driven" server, which is admittedly a fairly old 
>implementation technique.

Using a dictionary based approach is not a bad thing and will work for many
cases. 
The question is only how powerful the language for the dictionary has to be.
It could be just a "attribute name", "attribute code" and "data type".  

Regarding the "data type: Looking at the dictionary provided with FreeRADIUS
I noticed that there are datatypes support that are not listed in the RADIUS
Design Guidelines document.

Additionally, FreeRADIUS support some form of scripting also in addition the
to the dictionary, see http://wiki.freeradius.org/Configuration. 

>Such servers may have auxiliary "policy servers" that make 
>more complex decisions about authorization data than is 
>possible with simple attribute matching schemes or user group 
>membership schemes.  The relevant point of discussion, 
>however, is the on-the-wire RADIUS message format.

I am not saying that everyone should come up with the most complex attribute
formats. 
If one can avoid a custom attribute format then this is certainly
appreciated as it will lower the time it takes to implement a specific
functionality.

BUT: 

* If I take certain Diameter documents and I want to provide the
same/similar functionality in RADIUS then I cannot use the "simple"
attribute encoding. Example: Diameter QoS attribute. In that case I have to
come up with my own RADIUS attribute encoding for this purpose. 

* If I have features that already require additional code at the AAA server
(like the location stuff) then it does not make a big difference whether I
have to write a few lines more or less -- I have to touch the code base
already anyway. 

Even though these cases seem to be implicitly covered by the RADIUS design
guidelines document I still got beaten up with the RADIUS GEOPRIV document. 

>
>RADIUS was designed to provision pretty simple things.  It 
>originally envisioned each attribute as having an "atomic" 
>value, not some complex, structured message.  I understand 
>that AAA servers today attempt to provision more complex 
>things, and this is wherein the friction results.
>Should RADIUS be extended, much as Diameter has, to support a 
>more complex and nuanced set of provisioning capabilities? 

RADIUS has already been extended to provide more than "simple things". 
Example: Key distribution in Wimax. 

I believe there is value in documenting what the perceived mode of operator
for a protocol is. 

> If 
> so, then why do we need Diameter? :-)

Folks use the protocol they are familiar with for their favorite purpose
(even if it has nothing todo with AAA anymore). There are certain groups
that are more familiar with RADIUS and other's that bought into Diameter. It
is just a protocol and both of them are not difficult to implement. 

So, I don't see a problem with regard to this aspect. 

>
>>> So, what you are suggesting is that the syntax and semantics of 
>>> RADIUS attributes are contextually dependent on some policy 
>decision 
>>> that is opaque to the RADIUS client, proxies, etc?  I think 
>that's a 
>>> Very Bad Idea (tm) and falls under the recommendation against 
>>> polymorphic attribute design.
>>
>> implementation choices.
>I see.  I guess I still disagree.  Yes, anything, no matter 
>how complex, convoluted and baroque can be made to 
>interoperate with sufficient attention to detail.  A pig, 
>given sufficient thrust, can be made to fly.  :-)
>
>> abstract language for the developer for business logic, parsing, msg 
>> handling, etc.
>

Yes. 

>
>I think that the basic issues here is that there is a 
>disconnect between the consensus position of the RADEXT WG (to 
>keep things pretty simple) and need you are describing to 
>provide [near] capability parity with Diameter.  
Well. I would like to hear from other folks in the group whether they think
RADIUS server implements deployed in larger networks are so simple. A
Diameter implementation can also be pretty simple if you don't make use of
certain features and extensions. 
As such, this is very little todo with the protocol itself rather with the
features that folks want to accomplish. 

As an example: Consider the work in the NEA working group that has an impact
to the AAA server. Simple? Not really. Will people use and deploy it? Who
knows. 

Ciao
Hannes

---

From: Alan DeKok <[email-masked]>
Date: Sat, 27 Dec 2008 15:14:52 +0100

> the university space and enterprise environment it could be useful. 

  The WiFi roaming people are interested in this.  It permits them to
extend the enterprise environment across global roaming consortia.

> solutions or to switch to OpenDiameter etc. 

  The WiFi roaming people are also interested in this, especially to
simplify connections (avoiding IPSec), and to minimize lost packets in
EAP sessions.

> There are many reasons -- none of them have anything todo with technical

  "Install base". :)

> Design Guidelines document.

  Yes.  One word: WiMAX.

> to the dictionary, see http://wiki.freeradius.org/Configuration. 

  It has a simple policy language that is not Turing complete.  The
policy language also cannot (currently) decode attributes of complex
format.  The data types are still dictionary driven.

> I believe there is value in documenting what the perceived mode of operator

  I agree.

> is just a protocol and both of them are not difficult to implement. 

  Hmm.... I would beg to differ. But that's not part of this discussion.

> RADIUS server implements deployed in larger networks are so simple.

  Yes.

> A

  No opinion... I lack sufficient experience.

> to the AAA server. Simple? Not really. Will people use and deploy it? Who

  NEA is complicated.  See the NEA list archives for my opinions.

  That being said, it will likely get implemented... like WiMAX.

  Alan DeKok.

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 27 Dec 2008 21:32:45 +0200

Hi Bernard, 

Maybe I was misunderstood. 

I am not asking for RADIUS to become Diameter (even though the group is
heading into that direction in a step-by-step fashion already). 

Instead, I am asking for something different. I would like to have a bit
more reality touch regarding what can be done with the encoding in RADIUS
today and where custom encoding is necessary. 

To give you an example: Some time back when RFC 4675 was written it was
state-of-the-art to define an attribute as:

User-Priority-Table

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

Where 'String' represented a customing encoding. Other attributes in the
same document followed the same format. 

Given the available data types this was essentially the only choice to
comply with the idea of the data dictionary and the desire to have
everything be covered under the available data types. 

The dictionary might look like: 

ATTRIBUTE      User-Priority-Table     59         String 

Today, the encoding of RFC 4675 might quite likely be different and there is
still a lot of possibility to argue around why this is still a good
encoding. 

Whether the AAA server had to be updated in order to provide additional
parsing capability depends a lot on the procedure how some of these
attributes (and the values in them) get introduced into the system in the
first place. In some systems they might be statically provisioned into a
database and just retrieved without any additional logic and in other
systems they would be dynamically generated and there might be some logic
behind all this stuff. 

Now, the extended attributes draft extends the limits a bit. 

Still, there is this tendency to label custom encoding (like the one from
above) as really bad (by calling it "interoperability and deployment issues"
or see the discussion in Section 2.1.4 of draft-ietf-radext-design-05.txt
regarding "Complex Attributes and Security"). 

I guess nobody would argue that attributes that can have a simple encoding
are supposed to get unnecessarily complex. 

However, I would like to present the story in a way that custom encoding is
a side-effect of the design constraints that are introduced by the work the
group did. If you want something that does not fall into the "simple scheme"
(which btw happens quite often these days) then a custom encoding is more
difficult to avoid. 

There is nothing bad about this. The reason for this is largely based on the
fact that implementers have seen custom encoding already for a while and
hence they have found ways to deal with it.

Maybe what I should be doing is to go through the RADIUS Design Guidelines
draft and to make detailed text proposals to make it clearer what I actually
mean. 

Ciao
Hannes

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Bernard Aboba
>Sent: 27 December, 2008 00:18
>To: 'D. B. Nelson'; [email-masked]
>Subject: RE: Question regarding draft-ietf-radext-design-05.txt
>
>"I think that the basic issues here is that there is a 
>provide [near] capability parity with Diameter."
>
>Indeed, at various points with the RADEXT WG, questions have 
>come up relating to adoption of one or more features of 
>Diameter, and WG consensus has lined up with the RFC 3127 assessment:
>
>1) during the discussion on Extended Attributes, the question 
>arose as to whether RADIUS should adopt the Diameter AVP 
>format.  The WG consensus was against this, and as a result 
>only modest extensions (for tagging and additional attribute 
>space) were adopted. 
>
>suitability of the RFC 3539 watchdog timer and failover logic. 
> Again, WG sentiment does not appear to support a strict port 
>of the Diameter functionality to RADIUS.  
>
>So while it is possible (and potentially desirable) for RADEXT 
>to develop enhancements (such as Extended Attributes and 
>RADSEC), this falls considerably short of providing the full 
>functionality of Diameter. 
>
>
>
>
>
>
>--

---

From: "D. B. Nelson" <[email-masked]>
Date: Sat, 27 Dec 2008 16:09:59 -0500

Alan DeKok writes...

>> Regarding the "data type: Looking at the dictionary provided
>> with FreeRADIUS I noticed that there are datatypes support that
>> are not listed in the RADIUS Design Guidelines document.
>
>  Yes.  One word: WiMAX.

Yeah.  Some of the folks in WiMAX were among those who were early advocates
of deeply complex attribute encodings in RADIUS.  When the RADEXT WG didn't
embrace that design philosophy, the work got done outside the IETF.  If you
don't like the consensus you find here, you take the work elsewhere.  :-)

---

From: "Greg Weber" <[email-masked]>
Date: Sat, 27 Dec 2008 16:32:56 -0500

> don't like the consensus you find here, you take the work elsewhere.  :-)

I'm not sure if that accurately captures the chronological sequence of events,
but I'd like to remind that the original submission of the Design Guidelines
was back in July '05;  three & a half years back.
The WG has had trouble embracing _any_ design philosophy.
And the SDOs have business issues that must be addressed in a more
timely fashion.

---

From: "D. B. Nelson" <[email-masked]>
Date: Sat, 27 Dec 2008 17:02:20 -0500

Greg Weber writes...

> ...I'd like to remind that the original submission of the 
> Design Guidelines was back in July '05...

True enough.  As I've said very recently, the debate over complex attributes
dates all the way back to the chartering of RADEXT.

> And the SDOs have business issues that must be addressed in
> a more timely fashion.

This is more an issue of style that substance.  The work could easily have
been done in "classic" RADIUS attributes, albeit less elegantly.  There's a
school of AAA design style that wants to encapsulate the complex C-language
(or similar) "structs" that are used in the client and server code into
RADIUS attributes, as if RADIUS were some form of RPC mechanism.  :-)  The
debate is about whether or not that's a good idea.  It's certainly a valid
design approach -- the question is whether or not it fits well within
RADIUS.  If you view RADIUS as little more that a convenient transport for
application data, maybe it does.

---

From: "D. B. Nelson" <[email-masked]>
Date: Sat, 27 Dec 2008 17:32:17 -0500

> Given the available data types this was essentially the only 
> choice to comply with the idea of the data dictionary and the
> desire to have everything be covered under the available data
> types.

Yes.  The current RADIUS data types are very limiting, in that they
represent only scalars and octet arrays (strings).  I once suggested that we
try to address this in a fashion similar to the way SMI (SNMP) handles this
issue, i.e. to allow sequences of basic types to be encoded in an attribute
to form a complex type.  That went over like a lead balloon. :-(

> Whether the AAA server had to be updated in order to provide
> additional parsing capability depends a lot on the procedure how
> some of these attributes (and the values in them) get introduced
> into the system in the first place.

Sure.  The problem is, I suspect, that if one developer gets to standardize
attributes that were designed based on _his_ server implementation, that may
have impact on everyone else whose server is implemented differently.  What
turns out to be a natural encoding representation for a given implementation
/ system design may be cumbersome for another design, even though both are
fully "compliant" with the feature requirements.  Standards have to serve
the least (reasonable) common denominator.

---

From: "Greg Weber" <[email-masked]>
Date: Sat, 27 Dec 2008 17:58:36 -0500

> dates all the way back to the chartering of RADEXT.

I've read all the recent list traffic, but I'm not sure it's fair to
characterize this as an SDO run-around as opposed to a
failure of IETF process.  So, I'd be a bit careful about that.  :-)

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 28 Dec 2008 11:17:52 +0700

Hannes Tschofenig [mailto:[email-masked]] writes:

...

> Instead, I am asking for something different. I would like to have a
> bit more reality touch 

I wish you luck, but I'm afraid you're in the wrong WG for that...

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 28 Dec 2008 19:09:47 -0800

"There are more things in
heaven and earth, Horatio,

Than are dreamt of in your philosophy." 
WILLIAM SHAKESPEARE / Hamlet Act 1.
Scene V abt. 1601
> No. I am asking for considering the needs of some of the other usage environments as well.

At the risk of offending Shakespeare, perhaps its time to talk about the philosophy of the Design
Guidelines document. 

The Design Guidelines document has two major aspects to it:

  1. Articulating Design Guidelines for RADIUS standard attributes (e.g. not Extended Attributes). 
  2. Improving the efficiency and scalability of the standardization process for RADIUS attributes,
    both within the IETF as well as in other SDOs. 

Through aspects #1 and 2, the goal is to be able to address a wide range of needs in an
efficient way.  

> If you believe that different requirements may lead to different results then you are essentially with me.

By recognizing the unique needs of SDOs, and by establishing a new process for the creation and
review of RADIUS attribute document, the Design Guidelines document would seem
to be in agreement with this philosophy. 

For example, the Design Guidelines document, by articulating the RADIUS Design Guidelines,
allows, and even *encourages* SDOs to create their own RADIUS attribute specifications.  
As we learned in the process of developing RFC 4663 (and also to some extent after long 
experience with RFC 3427), it is becoming increasingly difficult for SDO participants to attend 
both SDO and IETF meetings in order to complete management (MIB or AAA) document.  
These documents are more efficiently done in only one SDO, and if the document doesn't 
involve protocol changes,  then the work can most efficiently be done outside the IETF. 

So, as I read it, the goal of the Design Guidelines document isn't to lead to further ossification
of the IETF process  -- but rather to a more productive and cooperative relationship
between the IETF and SDOs.   For example. the guidelines on complex attributes only 
apply to the RADIUS standard attribute space, not to the Extended Attribute space, or 
to SDO-Specific attributes.   So as I read it, the document isn't saying "you can't do 
this for an SDO-specific purpose", but rather, "if you wish to create attributes that are 
unlikely to be widely deployed outside your SDO, do so using SDO-specific attributes 
so as to to minimize impact on existing implementations". 

The overall philosophy that the IETF needs to focus its energy on the
*intersection* of requirements (including those from SDOs), not on the *union*
of requirements.  At the same time, the IETF needs to provide the mechanisms
by which SDOs that need work done can do that work themselves.  In principle
this approach enables design coherence to be maintained while at the same time
getting the IETF out of the critical path for much of the work that the SDOs need
to get done. 

> to be easily supported, which is not true.

Discussion of Extended Attribute design is out of scope of the Design Guidelines
document.  However, it *is* in scope for the Extended Attributes document.  So
I think you are pointing out an issue with the Extended Attributes document here. 

> to be documented in the document.

This is indeed a valid concern -- with respect to the Extended Attributes document. 

> cases. The question is only how powerful the language for the dictionary has to be.

By looking at all existing RADIUS implementations, I am sure we could find 
support for a considerable number of additional data types.  However, the
question being considered by this document is not "what is the union of
all implemented RADIUS datatypes", but rather "what is the likely 
intersection of data types used in RADIUS standard attributes".  
That question has been answered by examining existing RADIUS RFCs. 

However, the question of addition of data types *would* be relevant
to the Extended Attributes document, where presumably we are not
as concerned with backward compatibility. 

> come up with my own RADIUS attribute encoding for this purpose.

I do think this is a useful question to consider -- but I think that question
should be considered in the context of the Extended Attributes document,
not the Design Guidelines document. 

> guidelines document I still got beaten up with the RADIUS GEOPRIV document.

If you have suggestions for clarifying the language, feel free to submit an issue. 
However, in general, IETF beatings do not have to be linked to an offense, real
or imagined.  Rather the general philosophy seems to be "beatings will continue
until morale improves". :)

> I believe there is value in documenting what the perceived mode of operator

Sure.  The WMF has produced hundreds, even thousands of pages of
documentation, most of which is publicly available.  That they have
been able to utilize RADIUS for this purpose without changing the
protocol seems like a good example of the approach advocated by
the Design Guidelines document. 

> I think that's a Very Bad Idea (tm) and falls under the recommendation against

It should be noted that the Design Guidelines document is a BCP, and the
IETF is not the protocol police.  As a result,  SDOs are free to create
polymorphic attributes within their SDO-specific attribute spaces.   

>I believe that the argument that complex
>attributes lead to interoperability, deployment and security
>issues as stated in the draft is incorrect and can of course happen
>from certain implementation choices.

I would agree that a greenfield implementation could indeed support
a wider range of attribute complexity with little ill effects.  For example,
most Diameter implementations support a considerably wider range
of data types, grouping formats, etc. than most RADIUS implementations
do, because they were designed from the start to do this.

Where greenfield capabilities are being created (such as in the Extended
Attributes work), these arguments can and should be entertained.  However,
where we are talking about a protocol with dozens of legacy implementations,
the bar is set much higher, because the WG not only has to take into 
account the interests of those who want to do new things, but also the
impact on existing deployments.  Manding a forklist upgrade for existing
RADIUS servers which may be long off maintenance in order to add modest
new capabilities is not something that network administrators will appreciate. 

> to the AAA server. Simple? Not really. Will people use and deploy it? Who knows.

As far as I can tell, the "statements of health"/"posture attributes"
that are being designed in NEA WG fit within the "opaque blob" concept
articulated in the Design Guidelines document.  That is, there is no requirement
that a AAA server not implementing NEA change a single line of code.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 29 Dec 2008 14:17:10 +0700

Bernard Aboba [mailto:[email-masked]] writes:

...

> I think you are pointing out an issue with the Extended Attributes

At the risk of putting words in Hannes' mouth, I'm pretty sure that the
draft he believes gives the impression that Extended Attributes can easily
support the Diameter AVP structure _is_ the Design Guidelines draft; as he
points out, it would be impossible for a reasonable person to get that idea
from the Extended Attributes draft.

...

---

From: Alan DeKok <[email-masked]>
Date: Mon, 29 Dec 2008 08:39:46 +0100

> from the Extended Attributes draft.

  You must be reading a different version of the Design Guidelines
document than the one I'm editing.

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 29 Dec 2008 01:16:52 -0800

> from the Extended Attributes draft.

Looking at the Design Guidelines document, the term "extended"
is used in a number of contexts.  This may explain some of the
questions that Hannes raised. 

For example, in Section 2.2, the term is used to refer to the Extended Attributes document: 
2.2.  Extended RADIUS Attributes

   The extended RADIUS attribute document [EXTEN] defines a number of
   extensions to RADIUS.  The standard attribute space is extended by
   permitting standard allocations from within a specific subset of the
   VSA space; the format of extended attributes is defined; and extended
   data types are defined within that format.

   New specifications seeking to extend the standard RADIUS data model
   SHOULD examine [EXTEN] to see if their needs fit within the extended
   RADIUS data model.

In Section 3.1.2, the term is used to refer to RADIUS VSAs in general:

   As discussed in [RFC2865] Section 5.26, the vendor space is intended
   for vendors to support their own extended attributes not suitable for
   general use. 

In Section A.1.2, the term "Extended" is used to refer to data types. 
However, it is not clear whether this advice is only applicable to
RADIUS standard attributes (which I believe is the case), or whether
it applies to VSAs or SDO-specific attributes. 

A.1.2. Extended data types

   Where possible, the data types defined above in Section A.1.1 SHOULD
   be used.  The extended data types defined in [EXTEN] SHOULD be used
   only where there is no clear method of expressing the data using
   existing types.

   Does the data fit within the extended RADIUS data model, as outlined
   below?  If so, it SHOULD be encapsulated in a [EXTEN] format RADIUS
   VSA.

      * Attributes grouped into a logical container.
        This does not include nested groups.
      * Attributes requiring the transport of more than 247 octets of
        Text or String data.  This includes the opaque encapsulation
        of data structures defined outside of RADIUS.  See also Section
        A.1.3, below.

In Section A.5, the term "extended" is used to refer to SDO-specific
data types:

   Note that the points listed above do not relax the recommendations
   discussed in this document.  Instead, they recognize that the RADIUS
   data model has limitations.  In certain situations where
   interoperability can be strongly constrained, a data model extended
   by the SDO or vendor MAY be used.  

The term is also used in Section B.8, this time in reference to the
Extended Attributes document:

   Future specifications that attempt to obtain similar
   functionality SHOULD use the extended types from [EXTEN].

Overall, in looking over this text, there does seem to be some possibility
of confusion relating to the applicability of the document (which I believe
only applies to attributes within the RADIUS standard attribute space). 

However, none of the above text would seem capable of leading a reader
to believe that the Diameter AVP format was supported.  Or am I missing
something?

---

From: Alan DeKok <[email-masked]>
Date: Tue, 30 Dec 2008 08:12:02 +0100

> questions that Hannes raised. 

  I will update the document to ensure that the "extended" term is used
only in reference to the extended attributes document.

  Alan DeKok.

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 31 Dec 2008 17:50:01 -0500

>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+>
>
> Where 'String' represented a customing encoding.

OK, let's examine this case a bit further.  The string value is composed as
follows:

      The String field is 8 octets in length and includes a table that
      maps the incoming priority (if it is set -- the default is 0) into
      one of eight regenerated priorities.  The first octet maps to
      incoming priority 0, the second octet to incoming priority 1, etc.

That is to say, it is an octet array -- a singly dimensioned array of
one-octet values.  That seems to me to be the very definition of the base
RADIUS data type "String".  I see no issue here.

> Today, the encoding of RFC 4675 might quite likely be different and 
> there is still a lot of possibility to argue around why this is still
> a good encoding.

I think you need to use a more complex example to illustrate your point.  An
octet array is a base data type.  To stretch the capabilities of "classic"
RADIUS, you need to attempt to encode the equivalent of C-language
structures, arrays of structures, structures of arrays, or structures of
structures.

> attributes (and the values in them) get introduced into the system in
> the first place.

Well, that sounds like a user interface discussion, and thus out of scope
for RADIUS attribute design.  In the example you have given, the
User-Priority-Table can be treated by the AAA server as a fixed length
string of 8 octets.  Parsing may be required to enter the values into the
local database, but it's not required during authentication request
processing.

> In some systems they might be statically provisioned into a
> database and just retrieved without any additional logic...

Right.

>... and in other systems they would be dynamically generated and there
> might be some logic behind all this stuff. 

Perhaps.  What you are suggesting is that the user interface (UI) of the AAA
server might be replaced or supplemented by an application programming
interface (API).  Sure.  But that doesn't make the needs of the API a matter
of concern for the RADIUS on-the-wire message format.  That's all we
typically standardize, right?  The on-the-wire message format.

I think we need to apply a little judicious software architecture here.
While all sorts of auxiliary policy engines, data base interfaces, proxy
mechanisms, and other added value applications might be utilized by an AAA
server in "fetching" the values to populate attributes (AVPs), that doesn't
mean that those elements are part of the AAA server.  They may be packaged
as one deliverable for engineering or marketing reasons, but architecturally
they are logically separate entities.  If we always attempted to accommodate
complex systems, composed of multiple cooperating components, every time we
designed any component-level on-the-wire protocol in the IETF, we'd never
get anything accomplished.  I think it's a mistake to attempt to do that
here.

Now, there are other reasons that developers want to use complex attributes,
which don't hinge on system integration issues.  There are data objects that
a server may want to provision in a NAS that are inherently multi-part.  One
classic example is cryptographic keys, which often have a cipher-suite name,
a key name, a lifetime, and a scope that need to be attached to each key.
In that example there is no way to get around the need for structured data.
The question is how to achieve the structuring.

Is the existing tagging mechanism of the Extend Attribute draft sufficient?
I think the answer is yes, unless you want to have multiple keys that are
somehow associated with other attributes in the message (which would require
two distinct tag fields).  The question the RADEXT WG has tried to grapple
with is how complicated do we need to get?  What's the simplest attribute
encoding design that covers 80% of the likely use cases?  I, for one, am
willing to relegate the remaining 20% of use cases to Diameter-only
solutions. :-)  YMMV.

> Still, there is this tendency to label custom encoding (like the one
> from above) as really bad (by calling it "interoperability and deployment
> issues" or see the discussion in Section 2.1.4 of draft-ietf-radext-
> design-05.txt regarding "Complex Attributes and Security").

IMHO, the reason that these encodings are "bad" is two fold: (1) they do not
support the needs of data dictionary driven server implementations, and (2)
the technique for encoding them is ad-hoc (based on the personal design
choices of developers), which precludes any single set enhancements to data
dictionary driven server implementations which might allow them to deal with
a broad class of such attributes.