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 21:12:51 +0200

Bernard writes:
> 
> 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.
> 
That would be fine as it will go through the normal consensus building 
process. If times/circumstances change we must re-evaluate and sometimes
that leads to changes in our earlier documents.

I was just worried that you would do this simply by posting an erratum,
which seems not the best/correct way of handling it, specifically given
earlier conscious evaluation of the topic (or so I recall).

> 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.
> 
Looking forward to a possible upcoming document.

Bert
> 
> On Fri, 20 Aug 2004, Wijnen, Bert (Bert) wrote:
> 
> > 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 17:24:37 -0700 (PDT)

> earlier conscious evaluation of the topic (or so I recall).

The early discussion has indicated that this issue deserves more
consideration (and text) than an errata can provide.

> Looking forward to a possible upcoming document.

I look forward to writing it ;)