Subject: Re: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new A pplication-ID

From: Belling Thomas <[email-masked]>
Date: Thu, 2 Sep 2004 17:00:09 +0200

Dear all,

I am new on this email exploder and thus ask to be excused to comment this famous issue at a very late time.
However, it seems that you intend to invetigate this in more detail, and this seems appropriate.

It seems that some usefull features of the applications ID were forgotten in original analysis, in particular when updating applications:
Suppose you want to update to a new version of an application with additional mandatory AVPs.
Suppose also that the new version obtains a new application ID, 

(a) Routing:
A relay agent may use the application ID to route a request towards a server that supports the new or old version of the application . This may be usefull during a transition period when a network is beeing updated.

(b) Capability Negotiation:
An updated client capable of using both the new and the old version of an application could use the Capability exchange to find out if updated servers are already available

I am aware that certain applications add an internal version negotiation mechanism, which probably provides an alternative  solution for (b). I doubt a full substitute for (a) is possible.

From the analysis below it is clear that there may be an inflation of application IDs due to inheritance issues.
Sticking to the view that an application ID is only a last resort indeed conflicts with the fact that additional AVPs frequentley require the ´M´bit.

It is probably also true that more substantial changes such as changes to the state machine or new messages are much less frequent than the addition of mandatory AVPs.

The concern about the the bureaucratic overhead could also lead to a completly different conclusion: Accept that new application IDs will be frequent and therefore reduce the burden (e.g. expert review) to grant them. You may apply stricter criteria for more substantial changes (state machine, messages). This may result in a kind of inheritance in applictions which is documented in the standardistion texts, but not in the encoding of application IDs.

Regards, Thomas

----------------------------------
Dr. Thomas Belling
Siemens AG           
Sankt-Martin-Str. 76 
D-81541 München Germany
ICM N PG NT ST N1
MCH M 34 307
Tel     +49 89 636 75207
Fax     +49 89 636 75577
Mobile  +49 172 2974678
Email   [email-masked]

----------------------------------------------------------------------------------------------
RFC 3588, Section 1.2.3 describes when a new authentication Application
Identifier is needed.  Section 1.2.4 describes when new accounting
Application Identifiers are required.

Included in the list of conditions requiring a new Application-ID is:

"   -  Adding new AVPs to the command, which have the "M" bit set."

Given the discussion since the publication of RFC 3588, I now believe that
the above sentence is in error.  A new Application-ID should not be
required due to addition of AVPs to an application, whether the mandatory
bit is set or not.

I am curious what the WG thinks about this.  Given that we are just now
getting ready to publish Diameter applications as RFCs, it is possible to
correct this mistake.  Below I argue that letting this sentence remain in
the spec could prove costly.

ANALYSIS

Section 1.2.3 states:

"An implementation MAY add arbitrary non-mandatory AVPs to any command
defined in an application, including vendor-specific AVPs without
needing to define a new application."

So addition of an AVP by itself does not require a new
Application-ID, if the 'M' bit is not set.

So what is it about the 'M' bit that changes the situation so
fundamentally?

Let's review the purpose of the 'M' bit.

The purpose of the Mandatory bit was to enable implementations
that receive an AVP they do not support to determine whether they can
ignore that AVP, or whether a fatal error has occurred.

In other words, the purpose of the Mandatory bit was to enable Diameter
applications to be extended while maintaining well defined behavior.

Given this, if a Diameter application were to be extended with new AVPs
without obtaining a new Application ID, what happens?

Since no new Application-ID is used, Diameter peers will negotiate
capabilities with the existing Application-IDs, oblivious as to whether
new 'M' bit AVPs will be used or not.  As a result, Diameter connections
will be established all along the path between the Diameter peers.

If the new AVPs do not have the 'M' bit set, then a Diameter peer can
ignore them, presumably without harm.  If the AVPs have the 'M' bit set,
then a Diameter peer doesn't support them, then a fatal error
will result -- but Diameter error messages will make it clear what the
problem was.  What is done on receipt of the error message is
implementation dependent -- but one possibility would be to stop sending
the offending AVP to the peer that objected.

Note that in most cases, Diameter agents will not care about new AVPs,
whether they have the 'M' bit set or not.  Relays and Redirects won't
care.  Proxies might care -- but if they do then they can send their own
fatal errors.

Now let us look at what happens if a new Application-ID is required.
Since Diameter peers exchange the supported Application-IDs within the
CER/CEA exchange, if the new Application-IDs are not supported by one or
more peers along the path, then the Diameter messages won't get routed to
the destination.  The end result is  the same -- an attempt to send a
non-understood AVP with the 'M' bit set will result in an Error-Message
coming back, but now the error message will be returned from an
intermediary unable to find a Diameter peer to deliver to, rather than
from the endpoint peer.

This is a bit like the distinction between receiving a "host unreachable"
ICMP message and a "port unreachable" ICMP message.  Not a great
difference.

However, consider the downside to requiring a new Application-ID due to
addition of a new mandatory AVP:

* Proliferation of Application-IDs.

What if it is necessary to extend an application with multiple
additional mandatory AVPs?  Do we now need a new Application-ID for
each potential set of mandatory AVPs?  For example, what if we want to
extend Diameter EAP with additional wired 802 VLAN attributes as well as
some WLAN attributes and perhaps some filter attributes?  Do we need to
obtain 3 new application-IDs?

Or as an alternative, do we require each application to support
versioning?

* Additional work in intermediaries.  Do intermediaries now need a
"Dictionary" of Application-IDs?  Why isn't an AVP dictionary sufficient
(if one is needed at all)?

* Inheritance effects.  Diameter EAP depends on NASREQ.  Say I want to
extend NASREQ with some additional filter attributes.  Does this mean that
both NASREQ and EAP applications need new Application-IDs to support this?

* Bureaucratic overhead.  New Application-IDs are allocated by Expert
Review.  Who is volunteering to be the Expert to "review" all these new
Application-IDs?  Why isn't review of the new AVP definitions sufficient?

Based on the limited upside and substantial downside of requiring new
Application-IDs due to addition of AVPs with the 'M' bit set, my
conclusion is that the sentence requiring this in RFC 3588 was an error.
Assuming that the AAA WG agrees with this, then my recommendation is to
post an errata to the RFC Editor to this effect.

----------------------------------
Dr. Thomas Belling
Siemens AG           
Sankt-Martin-Str. 76 
D-81541 München Germany
ICM N PG NT ST N1
MCH M 34 307
Tel     +49 89 636 75207
Fax     +49 89 636 75577
Mobile  +49 172 2974678
Email   [email-masked]

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 2 Sep 2004 08:44:13 -0700 (PDT)

> (a) Routing:
> A relay agent may use the application ID to route a request towards a server
> that supports the new or old version of the application. This may be useful
> during a transition period when a network is beeing updated.

For this to work, intermediaries in the path first have to be updated
to support both the old and new versions.  Otherwise, the request will
be rejected before it gets to the "new" server.

> An updated client capable of using both the new and the old
> version of an application could use the Capability exchange to find out
> if updated servers are already available

Capabilities negotiation only works on a hop-by-hop basis, so it can't be
used to discover if updated servers are available, only updated
intermediaries.  The client has to send a packet to discover if updated
servers exist.

> I am aware that certain applications add an internal version
> negotiation mechanism, which probably provides an alternative  solution
> for (b). I doubt a full substitute for (a) is possible.

Versioning can only ensure that the client and server speak the most
advanced version that they both support.  Application-ID routing can
help a client route a request to a server supporting the desired version,
if such a server exists.

> Sticking to the view that an application ID is only a last resort indeed
> conflicts with the fact that additional AVPs frequently require the
> ´M´bit.

Application-IDs are a last resort because of their intrinsic limitations.
Applications which have discrete "versions" can be handled gracefully by
allocating a new Application-ID.  However, in the case of applications
which may have a number of "extensions" the number of required
Application-IDs (and associated intermediary upgrades) gets out of hand
quickly.

> It is probably also true that more substantial changes such as changes
> to the state machine or new messages are much less frequent than the
> addition of mandatory AVPs.

Yes, I think that's true.

> The concern about the the bureaucratic overhead could also lead to a
> completely different conclusion: Accept that new application IDs will be
> frequent and therefore reduce the burden (e.g. expert review) to grant
> them. You may apply stricter criteria for more substantial changes
> (state machine, messages). This may result in a kind of inheritance in
> applictions which is documented in the standardistion texts, but not in
> the encoding of application IDs.

Application-IDs are already allocated by expert review.  Are you
suggesting that something less should be required (First Come, First
Served)?

Since there are already stricter allocation requirements for new commands,
mandatory AVPs, etc.  it's not clear to me that we need to increase the
difficulty of allocating Application-IDs depending on the underlying
reason for the request.