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

From: "STURA Marco Consultant" <[email-masked]>
Date: Thu, 19 Aug 2004 12:45:16 +0200

Hi Bernard,

I fully share your view and analysis. Therefore I support sending an RFC
3588 errata as you recommend.

Regards
Marco

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]] 
Sent: Thursday, August 19, 2004 12:30 PM
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: <[email-masked]>
Date: Fri, 20 Aug 2004 09:53:46 +0300

Bernard,

This sounds like a reasonable proposal. I think we may need to improve
the text for why a new Application-ID would be needed.  I guess the
main driver would be the need for new command codes.  However, I think
we may need to work on a BCP on creating new Diameter Applications.

John

> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> ext Bernard Aboba
> Sent: 19 August, 2004 13:30
> To: [email-masked]
> Given the discussion since the publication of RFC 3588, I now 
> believe that
> required due to addition of AVPs to an application, whether 
> the mandatory
> bit is set or not.
> 
> getting ready to publish Diameter applications as RFCs, it is 
> possible to
> correct this mistake.  Below I argue that letting this 
> sentence remain in
> more peers along the path, then the Diameter messages won't 
> get routed to
> extend NASREQ with some additional filter attributes.  Does 
> this mean that
> both NASREQ and EAP applications need new Application-IDs to 
> support this?
>

---

From: <[email-masked]>
Date: Fri, 20 Aug 2004 12:13:27 +0300

Lionel,

> About the need for new command codes, it is not clearly 
> explained in the RFC 3588 if a new command code is required 
> if the application FOO is reusing an existing command code 
> defined for the application BAR but modifying the command 
> code ABNF specification. In another way:
> 
> is it possible to use the same command code (allocated by 
> IANA in the range for standard commands) defined with 
> different ABNF specifications in their related Diameter 
> application specifications?
> 
> Based on information collected all along the RFC, I would 
> assume that the response is "NO". But I cannot find a clear 
> statement. However, I may be wrong in my understanding...

Well, I think it would mean what different ABNF is being used.
If the new application added new parameters, that would be OK.
I don't think it would be OK if existing parameters were dropped.

John

---

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Fri, 20 Aug 2004 11:39:09 +0200

John,
 
> Well, I think it would mean what different ABNF is being 
> used. If the new application added new parameters, that would 
> be OK. I don't think it would be OK if existing parameters 
> were dropped.

It is exactly my concern. Three kind of AVPs are used in the ABNF
specification: fixed, required and optional AVPs. And different rules
will be apllied based on the AVP type in the ABNF. There is no problem
to add/remove any optional AVP without modifying the command definition.
Rules concerning fixed and required AVPs are more ambiguous.

Lionel

---

From: <[email-masked]>
Date: Fri, 20 Aug 2004 15:39:18 +0300

Hi,

> application specifications?

So far my interpretaton has been that yes, it is possible
and that the Application-Id is used to identify the ABNF of the
command (in addition to Command-Code).

BR,
Mikko

> ext MORAND Lionel RD-CORE-ISS
> Sent: 20 August, 2004 11:41
> To: Loughney John (Nokia-NRC/Helsinki); [email-masked];
> [email-masked]
> Subject: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs requires
> new Application-ID
> 
> 
> John, Bernard,
> 
> > -----Message d'origine-----
> > De : [email-masked] [mailto:[email-masked]] 
> > De la part de [email-masked]
> > Envoyé : vendredi 20 août 2004 08:54
> > À : [email-masked]; [email-masked]
> > Objet : RE: [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs 
> > requires new Application-ID
> > 
> > 
> > Bernard,
> > 
> > This sounds like a reasonable proposal. I think we may need 
> > to improve the text for why a new Application-ID would be 
> > needed.  I guess the main driver would be the need for new 
> > command codes.  However, I think we may need to work on a BCP 
> > on creating new Diameter Applications.
> > 
> > John
> > 
> > > The purpose of the Mandatory bit was to enable 
> implementations that 
> > > receive an AVP they do not support to determine whether they can 
> > > capabilities with the existing Application-IDs, oblivious as to 
> > > whether new 'M' bit AVPs will be used or not.  As a 
> result, Diameter
> > > connections
> > > 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
> > > care.  Proxies might care -- but if they do then they can 
> > send their 
> > > own fatal errors.
> > > 
> > > 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
> > > extend Diameter EAP with additional wired 802 VLAN 
> > attributes as well 
> > > as some WLAN attributes and perhaps some filter attributes?  Do
> > > we need to
> > > "Dictionary" of Application-IDs?  Why isn't an AVP dictionary 
> > > sufficient (if one is needed at all)?
> > > 
> > this mean 
> > > that both NASREQ and EAP applications need new Application-IDs to
> > > support this?
> > > 
> > > 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?
> > > 
> > > 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

---

From: <[email-masked]>
Date: Fri, 20 Aug 2004 15:38:25 +0300

Hi Bernard,

> RFC 3588 indicates if you add AVPs with the 'M' bit set, a new application-ID is
> required, but optional AVPs don't require a new Application-ID.  Or were
> you thinking of other ABNF changes?
> 
> I'm proposing that addition of AVPs (whatever the 'M' bit setting) should
> not require a new application-ID (although one could be used if desired).
> I'm not as sure about subtraction of mandatory AVPs; that would appear to
> create interoperability problems.

Subtraction of mandatory AVPs would create interoperability problems, therefore
I think the command-code could not be re-used, so a new command code would be
necessary.

John

---

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Fri, 20 Aug 2004 14:55:25 +0200

Hi Bernard,

The original question was on the use of the same command code by different diameter applications.

Should the ABNF specification for this command code be remain unchanged for fixed/required AVPs

Or

if a fixed/required AVP is added/remove to/from the original ABNF specification, a new command code should be allocated (even if the command is used by different applications)?

Lionel

> De : Bernard Aboba [mailto:[email-masked]] 
> Envoyé : vendredi 20 août 2004 14:34
> À : [email-masked]
> Cc : MORAND Lionel RD-CORE-ISS; [email-masked]
> Objet : Re: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit 
> AVPs requires new Application-ID
> 
> 
> > Fixed AVPs need to be there.  Mandatory AVPs need to be 
> there as well, 
> > or an error will be generated.  Optional AVPs are exactly as 
> > advertised, they do not need to be present.
> 
> Yes, that was my understanding.
>

---

From: <[email-masked]>
Date: Fri, 20 Aug 2004 16:44:03 +0300

Hi,

> Subtraction of mandatory AVPs would create interoperability problems,
> therefore I think the command-code could not be re-used, so a new 
> command code would be necessary.

I think another solution is to change the Application-Id.

BR,
Mikko

> ext 
> Sent: 20 August, 2004 15:38
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: RE : [AAA-WG]: RFC 3588 Errata: Adding 'M' bit AVPs