Subject: [AAA-WG]: [issue] 'M' Bit at fault rules still not right

From: David Spence <[email-masked]>
Date: Mon, 25 Feb 2002 12:40:06 -0500

Subject: [issue] 'M' Bit at fault rules still not right

Submitter name: David Spence
Submitter email address: [email-masked]
Date first submitted: February 25, 2002
Reference: 
Document: Base
Comment type: T
Priority: S
Section: 4.1
Rationale/Explanation of issue:

   The AVP Flag rules tables in the various Diameter drafts specify in 
   which AVPs the 'M' bit MUST be set, in which AVPs it MUST NOT be set, 
   etc.

   However section 4.1 of the base draft states:

      A Diameter node that sets the 'M' bit in an AVP that is not
      defined in a given message's ABNF is at fault if the message is
      rejected.

   In the next paragraph it states:

      A Diameter node that rejects a message due to an unrecognized AVP
      with the 'M' bit set, and the AVP in question is defined in the
      message's ABNF, is at fault.

   These sentences make the criterion for setting the 'M' bit be whether 
   or not the AVP is listed in the formal syntax for the message in 
   which it appears.  This is in direct contradiction to the criterion 
   that the 'M' bit should be set according to the specification in the 
   AVP Flag rules table of the draft defining the AVP.
      
   Life gets complicated, however, when an AVP defined in one Diameter 
   Application or a vendor-specific AVP gets included in a message 
   defined in another Diameter Application.  This is allowed for most 
   Diameter messages because the "* [ AVP ]" construct appears in most 
   message specifications.
   
   So what happens if the sender of the message considers such an AVP to 
   be critical to its intent, but the recipient of the message does not 
   understand the AVP?  The answer is that an interoperability failure 
   happens.  Some have argued (I have at times) that Diameter's 
   open-ended extensibility is actually one of its weaknesses.
   
   At the AAA WG interim meeting in Santa Clara in May 2001, the 
   extensibility-is-good faction reached a compromise with the 
   interoperability-failures-are-bad faction that resulted in the at 
   fault rules that appear in section 4.1 of the base draft.  The issue 
   here is that it is important to get the rules right.
   
   Considering that a Diameter node may include non-standard AVPs, and 
   considering that it may be critical to the security or business 
   requirements of the parties involved to know whether or not such AVPs 
   are accepted and processed, and considering that interoperability 
   failures are not in the best interests of any of the parties 
   involved, I propose the following principles to govern setting of the 
   'M' bit:
   
      1) AVP specifiers should be encouraged to require setting the 'M' 
         bit of any AVP for which the interest of any of the parties 
         would be hurt were the AVP to be ignored.
         
      2) Implementors should be required to provide alternatives to 
         sending non-standard AVPs with the 'M' bit set.  These may 
         include:
         
         a) If a message is rejected because it contains a non-standard 
            AVP with the 'M' bit set, the implementation may resend the 
            message without the AVP, possibly inserting additional 
            standard AVPs instead.
            
         b) A configuration option may be provided on a system wide, per 
            peer, or per realm basis that would allow/prevent particular 
            non-standard, Mandatory AVPs to be sent.  Thus an 
            administrator could change the configuration to avoid 
            interoperability problems.
            
      3) An implementation that does not comply with the above 
         requirements is not compliant with the Diameter standard.
         
   Examples
   --------
   
   Example 1:  If I were to define a vendor-specific 
   Interlink-Wowee-Zowee-Filter-Rule AVP, I would specify that the 'M' 
   bit MUST be set (I certainly don't want the filters to be ignored). 
   An implementation sending this AVP would be compliant if, upon 
   receiving a rejection for a message containing the AVP, it re-sent 
   the message with the NAS-Filter-Rule AVP in place of the 
   Interlink-Wowee-Zowee-Filter-Rule AVP.  Alternatively, an 
   implementation could achieve compliance by offering a per-realm 
   configuration option to control what realms to send the 
   Interlink-Wowee-Zowee-Filter-Rule AVP to.
   
   Example 2:  NASCO NASes always include the NAS-Filter-Rule AVP in 
   Accounting-Request messages on the theory that inclusion of this AVP 
   in accounting records may be critical to some providers' auditing 
   requirements.  NASCO is permitted to do this because the construct 
   "* [ AVP ]" appears in the formal syntax of the Accounting-Request 
   message.  The 'M' bit is set because the table in section 2.1 of the 
   NASREQ standard requires it.  ACME Accounting Servers do not 
   understand the NAS-Filter-Rule AVP.  If they receive an Accounting 
   Request message for a NASREQ session that includes the 
   NAS-Filter-Rule AVP with the 'M' bit set, they reject the message.  
   Thus no accounting can ever happen between a NASCO NAS and an ACME 
   Accounting Server.  Who is at fault?  ACME argues that according to 
   Diameter-08, NASCO is at fault because neither of the tables in 
   section 10.2 of NASREQ list the NAS-Filter-Rule AVP.
   
Requested change:

   Replace the at fault rules in section 4.1 with the following text.  
   (Note: the editor may decide to move this discussion to another, more 
   appropriate section of the draft.)
      
      The 'M' bit MUST be set according to the rules defined for the AVP 
      containing it.  In order to preserve interoperability, a Diameter 
      implementation MUST be able to exclude from a Diameter message any 
      Mandatory AVP which is neither defined in the base Diameter 
      standard nor in any of the Diameter Application specifications 
      governing the message in which it appears.  It MAY do this in one 
      of the following ways:
         
      1) If a message is rejected because it contains a Mandatory AVP 
         which is neither defined in the base Diameter standard nor in 
         any of the Diameter Application specifications governing the 
         message in which it appears, the implementation may resend the 
         message without the AVP, possibly inserting additional standard 
         AVPs instead.
         
      2) A configuration option may be provided on a system wide, per 
         peer, or per realm basis that would allow/prevent particular 
         Mandatory AVPs to be sent.  Thus an administrator could change 
         the configuration to avoid interoperability problems.
      
      Diameter implementations are required to support all Mandatory 
      AVPs which are allowed by the message's formal syntax and defined 
      either in the base Diameter standard or in one of the Diameter 
      Application specifications governing the message.

---

From: <[email-masked]>
Date: Tue, 26 Feb 2002 14:29:04 +0200

Hi David,

Thanks for tackling this issue, its a bit tricky.  I agree with your
suggested changes - any objections adding this text to the base?

John

> -----Original Message-----
> From: ext David Spence [mailto:[email-masked]]
> Sent: 25 February, 2002 19:40
> To: AAA Working Group
> Subject: [AAA-WG]: [issue] 'M' Bit at fault rules still not right
> 
>