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

From: Bernard Aboba <[email-masked]>
Date: Thu, 19 Aug 2004 03:29:46 -0700 (PDT)

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.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 19 Aug 2004 14:18:34 +0300

Bernard,

Thanks for posting this, and yes, I also agree with your
analysis. I would in addition point out that the distinction
between a syntactically mandatory and a policy-wise mandatory
attribute is often fuzzy. And we have always allowed nodes
to reject a transaction if they have a policy that requires
something that wasn't sent or was sent with a wrong value.

For instance, do you require a particular AVP Foo-Parameter
because its your policy that you only serve link layer FOO
even if you use NASREQ, or do you require it because you
are doing NASREQ-Foo which has Foo-Parameter marked as
mandatory?

Of course, with NASREQ-Foo you can increase the granularity
of negotiation. But we are not prohibiting people to come
up with a new application identifier if their application
really is different. Just that you would not *have* to do it.
For instance, if people come up with three new security-related
(=> mandatory) new features usable in the network access
context, does this mean that one has to develop NASREQ-F1,
NASREQ-F2, NASREQ-F3, NASREQ-F1-and-F2, and so on just
to be able to mark the attributes as mandatory?

--Jari