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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 20 Aug 2004 15:59:28 +0200

I had/have a vague recollection that the discussion about the M bit was
part of the vendor extensions discussion that took place a few years 
back (was it Yokohama timeframe) and that had some heavy IESG 
involvmenet back then. SO I checked with IESG.

Below is what Harald recalls. So it seems this cannot/should not be sent
just as an erratum to RFC-Editor

Thanks, Bert

-----Original Message-----
From: Harald Tveit Alvestrand [mailto:[email-masked]]
Sent: Friday, August 20, 2004 13:53
To: Wijnen, Bert (Bert); Iesg (E-mail)
Subject: Re: Is this acceptable as erratum: RFC 3588 Errata: Adding 'M'
bit A VPs requires new Application-ID

I think this was quite deliberate, and should not be changed.
This is based on what happened in CERT-land, X.400-land and other places....

Act 1: Protocols are defined, with extension mechansims
Act 2: Multiple vendors field interoperable implementations
Act 3: Evil Vendor (TM) fields an implementation that uses a mandatory 
extension - yet claims conformance to the spec.
Act 4: Other vendors are unable to interoperate with Evil Vendor (TM) 
because they can't use his mandatory extension, and since it's mandatory, 
they can't even go on with reduced functionality.
Act 5: Evil Vendor (TM) has locked competitors out of his marketplace....

It's "embrace and extend". And the rule against new M-bit extensions was to 
try to push non-interoperable usage of the protocol towards the Diameter 
version of a "new port" (new Application-ID): "If you want to be 
incompatible, that's OK - but not in OUR back yard".

I won't say this is right in all cases.... there are multiple other ways to 
lock people out of a marketplace. But this was one small push towards 
making it a little more hard.

                  Harald
-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]]
Sent: Thursday, August 19, 2004 12:30
To: [email-masked]
Subject: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires new
Application-ID

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: Bernard Aboba <[email-masked]>
Date: Fri, 20 Aug 2004 11:31:18 -0700 (PDT)

Since some additional issues have arisen (such as command code
reuse), it's probably appropriate to write a short document on the
subject to clarify the issues, and update RFC 3588.

Note that we've been discussing IETF standard uses of the protocol, and
the interoperability problems caused by Application-IDs in that standard
usage.  Extension by Vendor-Specific AVPs requires more careful analysis,
but that's not been the focus of the discussion so far.  However, even
there, I believe that requiring a new Application-ID for *each*
vendor-specific AVP probably makes no sense.