[Dime] Protocol errors, 'E' bit and answer command CCF grammar

<lionel.morand@orange.com> Thu, 24 March 2016 09:24 UTC

Return-Path: <lionel.morand@orange.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 4EC3112D61C for <dime@ietfa.amsl.com>; Thu, 24 Mar 2016 02:24:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.929
X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 7pY-lvSUjavg for <dime@ietfa.amsl.com>; Thu, 24 Mar 2016 02:24:47 -0700 (PDT)
Received: from relais-inet.orange.com (relais-nor35.orange.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1622412D11B for <dime@ietf.org>; Thu, 24 Mar 2016 02:24:47 -0700 (PDT)
Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 85EF72022F for <dime@ietf.org>; Thu, 24 Mar 2016 10:24:45 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 5DF6212005B for <dime@ietf.org>; Thu, 24 Mar 2016 10:24:45 +0100 (CET)
Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0279.002; Thu, 24 Mar 2016 10:24:45 +0100
From: lionel.morand@orange.com
To: "dime@ietf.org" <dime@ietf.org>
Thread-Topic: Protocol errors, 'E' bit and answer command CCF grammar
Thread-Index: AdGFrvV8bx3AToVYQP+L8zMb7GLcDg==
Date: Thu, 24 Mar 2016 09:24:44 +0000
Message-ID: <6022_1458811485_56F3B25D_6022_8433_1_6B7134B31289DC4FAF731D844122B36E01E09641@OPEXCLILM43.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/vtaAljYHSw3pFwx6BynXwZ5HXAs>
Subject: [Dime] Protocol errors, 'E' bit and answer command CCF grammar
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Mar 2016 09:24:51 -0000


I would like to trigger a discussion on the 'E' bit in the command flags of the Diameter header and the consequences on the answer message format. This point will be discussed during the next IETF meeting but it would be nice to receive initial feedback on this issue.

The text below is a little bit long but I've tried to clarify as much as possible the issue to avoid confusion.




In the RFC 6733, it is said regarding the 'E' bit in the section 3:


         If set, the message contains a protocol error, and the message
         will not conform to the CCF described for this command.
         Messages with the 'E' bit set are commonly referred to as error
         messages.  This bit MUST NOT be set in request messages (see
         Section 7.2).

Looking at the section 7.2, we have:

   The 'E' (Error Bit) in the Diameter header is set when the request
   caused a protocol-related error (see Section 7.1.3).  A message with
   the 'E' bit MUST NOT be sent as a response to an answer message.
   Note that a message with the 'E' bit set is still subjected to the
   processing rules defined in Section 6.2.  When set, the answer
   message will not conform to the CCF specification for the command;
   instead, it and will conform to the following CCF:

      Message Format

      <answer-message> ::= < Diameter Header: code, ERR [, PXY] >
                        0*1< Session-Id >
                           { Origin-Host }
                           { Origin-Realm }
                           { Result-Code }
                           [ Origin-State-Id ]
                           [ Error-Message ]
                           [ Error-Reporting-Host ]
                           [ Failed-AVP ]
                           [ Experimental-Result ]
                         * [ Proxy-Info ]
                         * [ AVP ]

   Note that the code used in the header is the same than the one found
   in the request message, but with the 'R' bit cleared and the 'E' bit
   set.  The 'P' bit in the header is set to the same value as the one
   found in the request message.

When a protocol error occurs (e.g. DIAMETER_UNABLE_TO_DELIVER (3002) or DIAMETER_REDIRECT_INDICATION (3006)) when processing a request (e.g. DER), the answer must not conform to the normal CCF grammar of the answer command (e.g. DEA) but must conform to the grammar given in the section 7.2.

In the specific redirection error case, the trouble comes from that redirect information is put as potential information that you can find in normal answers for a lot of answer commands including in the base protocol commands, e.g. Session-Termination-Answer:

         <STA> ::= < Diameter Header: 275, PXY >
                    < Session-Id >
                    { Result-Code }
                    { Origin-Host }
                    { Origin-Realm }
                    [ User-Name ]
                  * [ Class ]
                    [ Error-Message ]
                    [ Error-Reporting-Host ]
                    [ Failed-AVP ]
                    [ Origin-State-Id ]
       -->   * [ Redirect-Host ]    
       -->       [ Redirect-Host-Usage ]
       -->       [ Redirect-Max-Cache-Time ]
                  * [ Proxy-Info ]
                  * [ AVP ]

It seems to imply that the normal answer CCF is used instead of the generic one defined in the section 7.2 of RFC 6733. It is not a real issue if you consider the STA CCF syntax as it is compliant with the generic answer message CCF.

But the same principle was applied to a lot of application-specific commands, e.g. Diameter-EAP-Answer:

      <Diameter-EAP-Answer> ::= < Diameter Header: 268, PXY >
                                < Session-Id >
                                { Auth-Application-Id }
                                { Auth-Request-Type }
                                { Result-Code }
                                { Origin-Host }
                                { Origin-Realm }
                                [ User-Name ]

                                [ ...SKIP... ]

                                [ Error-Message ]
                                [ Error-Reporting-Host ]
                              * [ Failed-AVP ]

                                [ ...SKIP... ]

                                [ Origin-State-Id ]

                                [ ...SKIP... ]

                              * [ Redirect-Host ]
                                [ Redirect-Host-Usage ]
                                [ Redirect-Max-Cache-Time ]
                              * [ Proxy-Info ]
                              * [ AVP ]

and there are not compliant with the generic answer message CCF grammar as the Auth-Application-Id AVP and Auth-Request-Type AVP are required in a "normal" answer. Therefore, if the 'E' bit is set in the answer, these required AVPs should not be present according to the section 7.2 of RFC 6733.

The redirection error case is a specific example but the issue exists for any protocol error (e.g. DIAMETER_UNABLE_TO_DELIVER) or even permanent error when:

   In error conditions where it is not
   possible or efficient to compose application-specific answer grammar,
   answer messages with the 'E' bit set and which comply to the grammar
   described in Section 7.2 MAY also be used for permanent errors

The text above explains why a generic answer command CCF is used when the 'E' bit is set. As soon as a protocol error is detected, there is no need to generate an answer that complies to the normal CCF grammar as the main information is given in the Result-Code (or Experimental-Result) + additional specific AVPs (e.g. Failed AVP, Redirect-Host AVP, etc.).

I think that the RFC6733 is correct regarding the generation of answers with the 'E' bit set. As a consequence, any command answer CCF grammar including the redirection information related AVPs are not correct (or not relevant regarding base protocol commands).
A a consequence, a general update procedure should be initiated to correct this issue. It could be done with a new RFC updating all the IETF RFC. It would be also a trigger for other vendors (including SDOs) to correct their own specification. This RFC should also reinforce that the generic answer message CCF grammar should be used as soon as the 'E' bit is set. It should also be clarified that some protocol errors are meant to be handled on a per-hop basis and that some errors should not be forwarded to other peers. It is just a proposal and another approach could be adopted.

It is not a question of beauty contest or a vain purist crusade. There are existing interoperability issues in the field, with implementations complying with an application specification do not correctly process answer with the 'E' bit set when AVP required in the normal answer CCF grammar are missing. We need to fix this issue and the approach described above is the proposed way to close the issue.


Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.