Subject: [AAA-WG]: Vendor-Specific Values

From: Paul Funk <[email-masked]>
Date: Tue, 01 May 2001 20:03:35 -0400

I'd like to trot out a suggestion that was first made within 
the RADIUS group.

A "Vendor-Specific Value" is an AVP whose attribute is a 
standard one but whose value has semantics defined by a 
particular vendor. Such extensibility is useful for 
Unsigned32 types that are really enumerations, such as 
Service-Type and Accounting-Record-Type.

For example, a vendor may offer services other than "Login", 
"Framed", etc., and may wish to extend the Service-Type 
AVP with the values it requires. Or, a vendor may wish to 
define an Accounting-Record-Type other than start, stop, 
etc.

Vendors and service providers routinely have such 
requirements, have always satisfied these requirements by 
defining what they pleased, and have not always bothered 
to go to IANA for permission.

One might argue that the workaround is to define the 
enumerations within a separate VSA. But this is problematic 
for a couple reasons.

First, it is useful for a Diameter server to recognize that 
a particular value is a Service-Type naturally, without 
having to figure out that Acme-Service-Type carries service 
type information.

Second, and more problematic, is that AVPs such as 
Service-Type and Accounting-Record-Type are defined as 
required AVPs within the Diameter command, and any vendor 
that replaced these AVPs with their own would be instantly 
non-compliant.

By adopting VSVs there is an added benefit that relates 
specifically to Diameter:

Currently, the only way for a vendor to define a new extension 
is to apply to the IANA. But by allowing VSVs, any vendor would 
be able to define its own values for Extension-Id. I think this 
ability is critical to motivate widespread use of Diameter for new 
applications.

Command codes and attributes are already extensible by 
vendors, but enumerated values and extensions are not.
VSVs effectively make Diameter completely vendor-
extensible, at the cost of a single bit in the AVP Flags.

Paul

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 2 May 2001 14:03:48 -0700

> define an Accounting-Record-Type other than start, stop, 

sure.

> to go to IANA for permission.

well, that is problematic. If vendors want to encode a new value
in an existing RADIUS attribute, and pick an unused value without
registering with IANA, then conflicts will occur.

> having to figure out that Acme-Service-Type carries service 

correct.

> that replaced these AVPs with their own would be instantly 

right.

> ability is critical to motivate widespread use of Diameter for new 

An interesting, if not dangerous, proposal.

> extensible, at the cost of a single bit in the AVP Flags.

I hear you, but question whether this is really necessary. I can appreciate
the desire to have a truly flexible protocol, but this can lead to many
other undesirable side effects.

The -03 base now includes lots of new text that is the result of conversations
I've had with IESG members and the chairs. Specifically, the following
section has been created:

 2.3.1  Defining new AVP Values

  Defining a new AVP value is the best approach when a new application 
  needs to make use of an existing Diameter extension, but requires that an
  existing AVP communicate different service-specific information (e.g.
  NAS-Port-Type set to avian carriers).

  When an existing AVP can be used to communicate the new information, this
  approach is preferred over creating new AVPs.

  In order to allocate a new AVP value, a request MUST be sent to IANA,
  with a detailed explanation of the value. Furthermore, if the command
  code on which the AVP value is to be used would require a different set of
  mandatory AVPs be present, the list of AVPs must accompany the request.

Now I am in the process of checking how complex it is to request a new 
value since I sent an e-mail to [email-masked] to request a new value for
a RADIUS attribute. If all goes well, the pain to register a new value
is near zero.

So I'd like to punt this one to the chairs and see what they think.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 3 May 2001 06:58:23 -0700

On Wed, May 02, 2001 at 08:48:54PM -0700, Jeff Meyer wrote:
> Pat,
> 
>   You sure are fast on e-mail!
> 
>   Could you point me to any thread in the mail archive where
> you went over this?
> 
>   I haven't been following the group that long.  And 
> if this is already discussed I'm really intested in 
> the deciding factors.

I will let you have fun the with archives, but this would have been
early last year. I will however, point to a requirement in RFC 2989:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           |         |         |         |
   |   Mandatory Compact       |         |    M    |         |
   |    Encoding               |         |    7    |         |
   |      b                    |         |         |         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   [b]  The AAA protocol's Accounting data format MUST NOT be bloated,
        imposing a large overhead for one or more accounting data
        elements.

This requirement was introduced by some folks that have had prior
experience with accounting using SNMP, and the problems that occured (they
can chime in at this point, if they like).

> 
>   I'm asking, because IPDR.org is looking at means to effectively
> create unique attribute identifiers for bulk self-describing delivery
> of accounting information and Diameter's flat structure 
> seems problematic in an environment where lots of new
> attributes will be defined.   Note that IPDR is strictly
> interested in the accounting aspect and not authorization/authen.

ok, and we've discussed this in the past. If IPDR requires an XML
like approach, a Diameter AVP could easily be defined to contain an XML
accounting record. 

This should be quite simple.

> 
>   The simplicity of just using integer identifiers seems
> appealing, but if the space of attributes grows like 
> the space of attributes for SNMP, not having a hierarchical
> structure seems like a problem.  Perhaps this type of
> growth isn't expected.

Correct, since the AAA WG has set a limit on Diameter's applicability. Of
course, if other folks (or WGs) want to use the protocol for other reason,
then we cannot stop them.

> 
>   Do you end up parcelling out ranges of ids to a given
> service, so that version 2, 3, 4... of that service
> don't end up with new identifiers which are scattered all 
> over the map?

Again, Diameter would allow an XML, or any other encoding mechanism, to be
carried within an AVP. Would this work?

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 2 May 2001 20:16:15 -0700

Yes, it was discussed, and abandoned.

Again, I don't believe this is a problem that must be solved. Registering
a new value with IANA is close to painless.

PatC
On Wed, May 02, 2001 at 08:21:17PM -0700, Jeff Meyer wrote:
> Hi,
> 
>   Was there ever a consideration of using Object Id's
> versus a flat id space?
> 
>   Vendors would then only need to perform one petitioning 
> exercise with IANA (to get an Enterprise Id, if they don't 
> already have one).
> 
>   Oid's also make partitioning the various numeric
> identifiers easier, because it is hierarchical,
> and allows the ids to be organized into meaningful
> groups.
> 
>   As far as dictionaries and registration, Harald Tveit Alvestrand,
> maintains a directory (albeit incomplete) at:
> 
>   http://www.alvestrand.no/harald/objectid/top.html
> 
>   The hierarchical nature lends itself to distributed
> directories (perhaps even DNS).  I'm not aware of any
> standards work in this area, but IANA registration for
> each new attribute doesn't sound that scaleable.
> 
>   The obvious downside is that OIDs require more bytes
> to be encoded than a single 32-bit integer.  However
> SNMP and LDAP seemed to be pretty successful using them.
> 
>   In theory the universe of OIDs already defined for
> various SNMP attributes could be reused as is if/when
> appropriate.
> 
> 
> Regards,
> 
>   Jeff Meyer
>   Hewlett-Packard
>   [email-masked]
>   
> 
> Pat Calhoun wrote:
> >

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 4 May 2001 08:42:35 -0700 (PDT)

> can chime in at this point, if they like).

Response bloating was one of the more significant problems uncovered with
SNMP usage in accounting. In cases where inbound traffic to the NAS is
causing congestion (more likely than outbound, in general), multiplying
the size of the Accounting Response by a factor of 3 or 4 is likely to
result in packet loss.

> > interested in the accounting aspect and not authorization/authen.
Actually, DIAMETER's attribute space is not limiting in this
situation. Just create a DIAMETER attribute that serves as an "opaque" bag
within which you can package your accounting data in the format of
your choosing. The rest of the DIAMETER Accounting Message can be thought
of as an "envelope" for that bag. Within the IPDR vendor-specific AVP
you can do whatever you want.

Note that Accounting servers often write the accounting message to
disk rather than examining the attributes in detail; in such
implementations, all accounting attributes are non-mandatory. Thus, it
may not even be necessary for the accounting server to support IPDR -- if
the accounting server implementation just writes the IPDR information
to disk,  a separate module can be written to parse it and process the
information after it has been stored by the accounting server.  

> > structure seems like a problem.  Perhaps this type of

Not really. If an "opaque bag" is used as described above, then you'll
only need 1 DIAMETER AVP no matter how big the space of attributes gets.