[Dime] Update of RFC7423: Use of the 'E' bit in the Diameter Header
<lionel.morand@orange.com> Tue, 12 July 2016 06:45 UTC
Return-Path: <lionel.morand@orange.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B509A12B007 for <dime@ietfa.amsl.com>; Mon, 11 Jul 2016 23:45:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dz4VSrx2zpsb for <dime@ietfa.amsl.com>; Mon, 11 Jul 2016 23:45:55 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B7CA12B016 for <dime@ietf.org>; Mon, 11 Jul 2016 23:45:55 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 9CD8726428B for <dime@ietf.org>; Tue, 12 Jul 2016 08:45:53 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.62]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 7DC0B23807E for <dime@ietf.org>; Tue, 12 Jul 2016 08:45:53 +0200 (CEST)
Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM5E.corporate.adroot.infra.ftgroup ([fe80::2912:bfa5:91d3:bf63%19]) with mapi id 14.03.0301.000; Tue, 12 Jul 2016 08:45:52 +0200
From: lionel.morand@orange.com
To: "dime@ietf.org" <dime@ietf.org>
Thread-Topic: Update of RFC7423: Use of the 'E' bit in the Diameter Header
Thread-Index: AdHcCJGU2tNioeXhQRq9v0m2cxk+Ag==
Date: Tue, 12 Jul 2016 06:45:52 +0000
Message-ID: <11308_1468305953_57849221_11308_8803_1_6B7134B31289DC4FAF731D844122B36E01EFEEBD@OPEXCLILM43.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.5]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.7.12.55416
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/xp4p8_IvxN5wMuakgiAkIcq2_ng>
Subject: [Dime] Update of RFC7423: Use of the 'E' bit in the Diameter Header
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: Tue, 12 Jul 2016 06:45:58 -0000
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.
- [Dime] Update of RFC7423: Use of the 'E' bit in t… lionel.morand