Subject: RE: [AAA-WG]: AAA WG Interim meeting dates

From: "Christian Huitema" <[email-masked]>
Date: Thu, 5 Apr 2001 11:11:26 -0700

I have a somewhat fundamental issue with the Diameter. Why is the IETF
trying to invent yet another marshalling protocol, instead of using
existing technologies such as XML or ASN.1? Radius made some sense,
because it was very well scoped and very limited in complexity. The
Diameter specification is much more ambitious than Radius; it attempts
to define a fully capable marshalling protocol, using the RFC process
and the IANA as a substitute for an interface definition language. If I
am developing a specific application protocol, why should I base it on
Diameter rather than ASN.1 or XML?

The answer to that specific issue will probably be given by the market.
If the application developers are not convinced by Diameter, they will
probably simply use something else. In any case, there are quite a few
detailed problems in the specification.

1) Mandatory use of SLP or SLPv2 for "Diameter service discovery"

This creates a dependency on SLP for very little benefit, and possibly
some harmful consequences. Diameter is primarily meant to be used for
AAA applications; these applications require some tight control; in
practice, that control requires some form of explicit parametrization of
the device. The DNS SRV mechanism already provides a layer of
indirection between the name of the server and its actual
implementation; there is no need for an additional mechanism. In any
case, the decision to use a local discovery mechanism rather than a
configuration mechanism belongs in the application documents, not in the
base spec.

2) AVP header format

As specified, it seems impossible to encode an attribute in less than 96
bits. This is way less efficient than Radius. This seems particularly
ill-suited to mobile applications, in which bandwidth is at a premium.
Having a 64 header per attribute means that in most practical
applications there will not be any advantage to using the binary format
of Diameter compared to more modern technologies such as XML; there will
also be no particular advantage compared to classic technologies such as
ASN.1/BER. If that is the case, why bother with Diameter at all?

Why do we believe that we need 32 bits to encode attribute types? It is
certainly possible to encode the combination of length, flags and
attribute type in a single 32 bit word, at least in the common case of
attribute length lower than 255. A format like the following would
feature the same amount of information in half the space, still allowing
for more attribute types than the IANA can possibly handle; if the
length is larger than 254, the AVP length is set to 255 and an optional
length field is added. Four bits are reserved for type indication,
discussed later.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           AVP Code            |P|V|M|r|t t t t|  AVP Length   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Extended length (optional)                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Vendor-ID (opt)                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...
      +-+-+-+-+-+-+-+-+

3) AVP Data Formats

In the spec, the data format is determined by the value of the AVP code.
This has an operational consequence: it becomes impossible to write a
monitoring utility or a logging utility without having a complete
dictionary. I suggest sticking a 4 bit "data type" field as a complement
to the AVP code

      1 - OctetString
      2 - Address
      3 - Integer32
      4 - Integer64
      5 - Unsigned32
      6 - Unsigned64
      7 - Float32
      8 - Float64
      9 - Float128
     10 - Grouped

By the way, it would probably be very practical to defined a "boolean"
type, of code zero, to encode a basic protocol flag.

4) Grouped attributes

In the case of the "grouped" attribute, we have a real problem of type
definition. Shall we require that all AVP codes in the group are present
in the dictionary, or can they be simply defined in the context of the
group? The latter does provide for much more flexibility, and is in line
with the practice of ASN.1 or XML.

Both ASN.1 and XML Schema Language provide way to define the structure
of grouping: order list, unordered set, array of elements. How do we do
this in Diameter?

Adding two categories for "XML text" and "ASN.1 BER" would actually make
a lot of sense.

5) Device-Reboot-Ind (DRI) Command

Having a mandatory Vendor-ID in the command creates a barrier to entry
for implementors: it requires that they first register with the IANA.
This should be optional. There is no reason to mandate the presence of a
vendor-id if no vendor extensions are used, a case which we hope should
be quite common.

6)  Extension-Id AVP in DRI command

The presence of an extension-id AVP is symptomatic of an unsolved
dilemma in the Diameter sprecification. Is Diameter a protocol framework
or a service specification? If it is a protocol framework, then the
extension is in fact the service; which server to use and which port
number to connect to will be determined by this service; negotiating the
extension at this point does not make any sense.

7) Host-IP-Address AVP in DRI command

What does that do in the presence of a NAT?

8) and many more issues, but we will need more time...

-- Christian Huitema

---

From: David Frascone <[email-masked]>
Date: Thu, 5 Apr 2001 14:00:11 -0500

> configuration mechanism belongs in the application documents, not in the

I read the mandate as:  If discovery is necessary.  And, in a mobile
environment, there needs to be some way for the mobile to find an AAA server,
right?  

> length field is added. Four bits are reserved for type indication,

I have no fundamental problem with your new AVP header.  In fact, I like it.
(I'd make one small change, though, and instead of using 255 in the length
field, I'd grab one of those unused bits to signal that the extended length
was being used.)

My complaint, however, is your timing.  It seems that every time the protocol
goes into last call, someone stops lurking and wants to make a serious
fundamental change.  

Many working groups/standards bodies are waiting for the IETF AAA protocol.
This really should have been brought up some time ago.

> type, of code zero, to encode a basic protocol flag.

Since you can't interoperate with other implementations without a dictionary,
I see no need to send data definition "on the wire".

> vendor-id if no vendor extensions are used, a case which we hope should

I agree with this comment.  I to prefer a vendor string over an IANA number.

I'm assuming it's easy for a company to get a vendor id, but what about 
someone testing a concept:  "Umm, can I get a "Dave's new Toy vendor id" ?

> extension at this point does not make any sense.

Sure it does.  Suppose you're trying to find a server to handle Mobile-Ip
authentication.  When you do your server discovery, there are 5 diameter servers
available, but only one handle Mobile-IP AAA.  By looking at the extensions, 
you'd know which one to use.

> What does that do in the presence of a NAT?

I'm sure, in the presence of NAT, that the Host-IP-Address would be the 
last routable proxy.  I don't think ANY protocol can be 100% NAT friendly.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 06 Apr 2001 01:06:20 +0300

Without discussing your more general input, I'll just

>Having a 64 header per attribute means that in most practical

It may be useful to note here that Diameter is being considered
for parts of the wireless _infrastructure_. That is, from (say)
base station to a home AAA server. There is plenty of bandwidth
available within that network even if it's quite different over
the actual wireless link. Usually, it's not the wireless phones
that are doing the accounting themselves, it's the network! In
conclusion I don't think this is an issue.

Jari

---

From: "Mark Jones" <[email-masked]>
Date: Fri, 6 Apr 2001 10:40:26 -0400

> > vendor-id if no vendor extensions are used, a case which we hope should

The Vendor-Id/Product-Name/Firmware-Revision AVPs also serve to identify the
peer regardless of whether it generates vendor-specific AVPs.

> I agree with this comment.  I to prefer a vendor string over an

If the AVP was only intended to be human-readable, I would agree. If my
Diameter server has to interpret it, I prefer a well-known integer. For
vendor string to be equally machine-readable, one would have to ensure that
every Diameter peer produced by the same large corporation had the same
well-known value. Otherwise how many permutations could we have of "Sun
Microsystems Inc."?

> someone testing a concept:  "Umm, can I get a "Dave's new Toy vendor id" ?

So this oft repeated "barrier to entry" is for those implementing a Diameter
device/server who have yet to form a company and so would be ineligible for
an IANA code. You're looking for something akin to the Experimental branch
on the SNMP MIB. Is that right?

Would the following text help?

"A Vendor-Id value of zero in the DRI is reserved and indicates that the
Diameter peer is in the experimental or concept stage and that an IANA
Private Enterprise Number has yet to be obtained by the implementor."

Regards,
       Mark

---

From: David Frascone <[email-masked]>
Date: Fri, 6 Apr 2001 09:42:02 -0500

> Private Enterprise Number has yet to be obtained by the implementor."

Hey!  I like it!  Any other opinions?

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 6 Apr 2001 09:23:04 -0700

>goes into last call, someone stops lurking and wants to make a serious

As time goes on, the bar will be continually raised until we *will*
be rejecting many changes that are too big. But that time is
not yet here.

DIAMETER only became an official AAA WG document after the February Interim
meeting. As a AAA WG document it is only an -01. The document is not yet
in last call. At this point, we have only closed off addition of major
new capabilities. So Christian's comments are not yet outside the window.
Let's keep the argument centered around whether the proposed change
makes sense, not on whether it's "too late."

One of the criteria for accepting DIAMETER on the IETF standards
track was that change control be ceded to the IETF.
In practice, this means that we need to demonstrate during IESG review
that WG input has been incorporated where appropriate. So when
WG members suggest changes, I would like to keep discussion focused
on whether they make technical sense, rather than just rejecting
them on the basis that "the protocol cannot be changed." Arguing
about whether changes can be accepted will only slow down the
process.

The IETF standards process is considered valuable because
IETF work product is generally of high quality. This is the result
of having a lot of smart people working on the protocol and
incorporating their input. After the WG has finished, we then
have The Supreme Court (the IESG) read the protocol
in order to flush out any other issues. By nature this is not an
ultra-fast process -- but it can be made to work without excessive
delay *if* the WG does its homework up front.

Getting a document to the IESG is easy -- it's getting it
past the IESG that is hard. I would like to make sure that DIAMETER
not only receives AAA WG approval, but also passes IESG
review on the first try, if possible. If WG review discloses
significant issues, there is no reason to believe that
the IESG would not also discover those same problems. So
getting the document to the IESG quickly won't speed up
the process -- they'll just send it back to us for more work.

So in summary, the fastest way to get DIAMETER done is to quickly
incorporate WG input.

>I see no need to send data definition "on the wire".

The reason that a data dictionary is needed is that the AAA server has to
have a way to figure out how to format the AVP based on user input. If
you used ASN.1 instead, you'd still have to have a MIB to provide this
same information. So the information requirements don't really change.

Unlike the AAA server, the NAS needs to understand the semantics of the
AVPs, in order to carry out the requested action. This typically requires
code, not just a data definition. So defining the data "on the wire"
wouldn't significantly change the work required on the NAS.

Where defining data "on the wire" would help is in situations (such as
accounting) where arbitrary data structures sometimes need to be
communicated. DIAMETER can carry ASN.1, XML, or any other payload
within its AVPs, so that this is not precluded. At IETF 50, we
discussed these applications, and decided that we should accomodate
them by enabling transmission of "opaque AVPs". We also decided that we
wouldn't re-write the protocol to do this, since most of the data that is
transmitted in AAA is fairly simple -- so it makes sense to
"optimize for the common case."

>you'd know which one to use.

Except that in practice, capabilities negotiation is really an end-to-end
function and the current DRI mechanism doesn't really accomplish that. Say
I'm trying to reach a AAA server two hops away that has Mobile IP
capabilities.
How does knowledge of the capabilities propagate upstream?

Why not just assume that (aside from policy actions by proxies) that the
packet will be forwarded to the AAA server, who will reject it if the
appropriate capabilities are not available? This would enable end-to-end
capabilities negotiation without the need for the DRI message.

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 10 Apr 2001 15:59:01 -0700

> > > vendor-id if no vendor extensions are used, a case which we

From a recent draft:

Vendor-ID
      In the event that the Command-Code field contains a vendor
      specific command, the four octet Vendor-ID field contains the IANA
      assigned "SMI Network Management Private Enterprise Codes" [2]
      value. If the Command-Code field contains an IETF standard
      Command, the Vendor-ID field MUST be set to zero (0).

There is no need for implementors to register w/IANA if they are
implementing a vanilla, standard Diameter peer.

> > someone testing a concept:  "Umm, can I get a "Dave's new Toy

Pick an unused ID.

> Private Enterprise Number has yet to be obtained by the implementor."

Unfortunately, this contradicts the general approach to commands (see
above).