[Dime] Update of RFC7423: Use of the 'E' bit in the Diameter Header

[<[e-mail]>]

Hi,

As discussed at the last meeting, here is a draft of a new section to include in the RFC7423bis clarifying the use of the 'E' bit in answer commands.
Please provide your comments. This text will be discussed in Berlin.

Regards,

Lionel

**********************
5.12.  Use of the 'E' bit in the Diameter Header

   As described in the section 3 of [RFC6733], the Diameter command
   header includes an 8-bit field named "Command Flags" field.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Version    |                 Message Length                                                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |R P E T r r r r|                  Command Code                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Application-ID                                                                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Hop-by-Hop Identifier                                                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      End-to-End Identifier                                                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  AVPs ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-

   These Command Flags are used to characterize the type of Diameter
   message being sent/received, i.e. request or answer ('R' bit),
   proxyable message ('P' bit), error message ('E' bit) and
   retransmitted message ('T' bit).  About the 'E' bit, the following
   definition is given:

        E(rror)

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

   Further details on the use of the 'E' bit are given in the section
   7.2 of the [RFC6733].  In this section, it is explained that when a
   request (e.g.  Diameter-EAP-Request) causes a protocol-related error
   i.e., DIAMETER_UNABLE_TO_DELIVER or DIAMETER_REDIRECT_INDICATION or
   any other error listed in section 7.1.3 of [RFC6733], the
   corresponding answer must not conform to the normal CCF grammar of
   the answer command (e.g.  Diameter-EAP-Answer) but must conform to
   the following generic grammar:

       <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 message format given above is not totally correct. If
   the Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION, the
   Redirect-Host AVP must be present.  The message format should be as
   follow:

       <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 ]
                   -->    * [ Redirect-Host ]
                   -->      [ Redirect-Host-Usage ]
                   -->      [ Redirect-Max-Cache-Time ]
                          * [ Proxy-Info ]
                          * [ AVP ]

   It could be argued that the "*[AVP]" allows the presence of the
   Redirect-Host AVP, Redirect-Host-Usage AVP and Redirect-Max-Cache-
   Time AVP.  However, as there is a clear condition for the presence of
   the redirection information in the answer in case the Result-Code AVP
   is set to DIAMETER_REDIRECT_INDICATION, it is better to include these
   AVP in the generic answer message CCF when the 'E' bit is set in the
   Diameter header.

   If it is used to report protocol errors, the 'E' bit can also be used
   to indicate permanent errors i.e., DIAMETER_UNABLE_TO_COMPLY or any
   other error listed in section 7.1.5 of RFC6733, as described in the
   following part of the introduction of the section 7.1.5 of [RFC6733]:

    "[...] 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.

   Besides describing the possible use of the 'E' bit for permanent
   error cases, the text above further clarifies the rational for an
   answer in a generic command format when the 'E' bit is set.  If an
   error is detected when processing the request at the Diameter
   protocol level, there is no need to generate an full answer complying
   to the CCF grammar of the answer command as defined in the application
   specification.  Furthermore, when this answer is generated by a
   Diameter node in the Diameter signalling path acting as a Diameter
   Relay agent, it is not even possible to generate such an application-
   specific answer as a Relay agent is by definition application-
   agnostic.

   As the main purpose of the answer is to notify the error in the
   process of the request, the pertinent information to provide is
   already contained in the Result-Code (or Experimental-Result) of the
   answer.  In addition, extra information that may also be present in
   the answer is useful for correcting the request or for debugging
   information (e.g.  Failed AVP, Redirect-Host AVP, etc.).

   When defining the commands for a new application, it is RECOMMENDED
   to specifically refer to the section 7.2 of [RFC6733] for the CCF
   specification for the answer command when 'E' bit is set.  AVPs that are 
   supposed to be only used when the 'E' bit is set SHOULD NOT be included
   in the definition of new answer commands e.g.  Redirect-Host AVP.  
   Diameter nodes supporting any application MUST expect to receive 
   answer commands that does not comply with the definition given in the
   application specification, as long as they are compliant with the generic 
   answer command's CCF when the 'E' bit is set.

   NOTE:  The IETF RFC 6733 [RFC6733] is not totally self-consistent as
      AVPs related to redirection information (Redirect-Host AVP,
      Redirect-Host-Usage AVP and Redirect-Max-Cache-Time AVP) are
      included in the CCF specifications of Diameter base answer
      commands (Re-Auth-Answer (RAA), Session-Termination-Answer (STA)
      and Abort-Session-Answer (ASA)) instead of just referring to the
      generic CCF syntax when the 'E' bit is set.  This could be
      misinterpreted as that "normal" answer commands can be used for
      providing redirection information.  Using as reference the IETF
      RFC 6733 [RFC6733], other standard Diameter applications have
      included the Redirect-Host AVP, Redirect-Host-Usage AVP and
      Redirect-Max-Cache-Time AVP in the CCF specification of the answer
      commands (e.g.  [RFC7155] or [RFC4006]).  In the same logic, the
      same approach has been adopted in most of the vendor-specific
      Diameter applications defining new commands.

   Moreover, protocol implementors SHOULD ensure that some protocol
   errors are only handled on a per-hop basis and are not forwarded to
   other peers.  For instance, the DIAMETER_REDIRECT_INDICATION is used
   to indicate to the request should be redirect to hosts that are
   supposed to be peers of the node receiving the answer.  If the
   receiver of the answer is a Diameter relay/proxy agent, it may
   attempt to redirect the request to one of the hosts identified by a
   DiameterURI in the answer.  If it is not able to forward the request
   to one of the identified hosts (e.g. no transport connection can be
   created with any of the identified hosts), the agent SHOULD return a
   DIAMETER_UNABLE_TO_DELIVER to the initiator of the request instead of
   forwarding DIAMETER_REDIRECT_INDICATION.  The same principle SHOULD
   apply with DIAMETER_TOO_BUSY and DIAMETER_LOOP_DETECTED.

_________________________________________________________________________________________________________________________

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.