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

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

John, Bernard,

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...

Lionel

> -----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
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of
> > ext Bernard Aboba
> > Sent: 19 August, 2004 13: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 05:28:03 -0700 (PDT)

> 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?

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.