Re: [Dime] Diameter retransmission -- to use same hop-by-hop and end-to-end IDs?

<lionel.morand@orange.com> Tue, 08 March 2016 15:00 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 C860E12D744 for <dime@ietfa.amsl.com>; Tue, 8 Mar 2016 07:00:45 -0800 (PST)
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 ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YJJXM_vuKv4 for <dime@ietfa.amsl.com>; Tue, 8 Mar 2016 07:00:43 -0800 (PST)
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 809AA12D724 for <dime@ietf.org>; Tue, 8 Mar 2016 07:00:42 -0800 (PST)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 07D7A22C8A2; Tue, 8 Mar 2016 16:00:41 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.2]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id C2B904C06B; Tue, 8 Mar 2016 16:00:40 +0100 (CET)
Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0279.002; Tue, 8 Mar 2016 16:00:40 +0100
From: lionel.morand@orange.com
To: Jouni Korhonen <jouni.nospam@gmail.com>, "dime@ietf.org" <dime@ietf.org>
Thread-Topic: [Dime] Diameter retransmission -- to use same hop-by-hop and end-to-end IDs?
Thread-Index: AQHRdmkXWX8Zpc/140CAmCJ2KnQeL59Poohg
Date: Tue, 08 Mar 2016 15:00:39 +0000
Message-ID: <30712_1457449240_56DEE918_30712_6072_1_6B7134B31289DC4FAF731D844122B36E01DFA14E@OPEXCLILM43.corporate.adroot.infra.ftgroup>
References: <E8355113905631478EFF04F5AA706E9830EB51A2@wtl-exchp-2.sandvine.com> <56DA1294.6010901@gmail.com>
In-Reply-To: <56DA1294.6010901@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.3]
Content-Type: text/plain; charset="iso-8859-1"
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.3.8.122717
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/fiOOVL16qEk_s9lBk-FHnZqctxI>
Subject: Re: [Dime] Diameter retransmission -- to use same hop-by-hop and end-to-end IDs?
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, 08 Mar 2016 15:00:46 -0000

Hi David,

I agree with Jouni.
See below for more details.

BR,

Lionel

> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen
> Envoyé : vendredi 4 mars 2016 23:56
> À : dime@ietf.org
> Objet : Re: [Dime] Diameter retransmission -- to use same hop-by-hop and
> end-to-end IDs?
> 
> Hi,
> 
> On top of my head.. and in a tired condition :)
> 
> 3/4/2016, 7:55 AM, Dave Dolson kirjoitti:
> > Hello Diameter experts,
> >
> > We've been looking to the specs in order to answer the question as to
> > whether a
> >
> > retransmitted Diameter request MUST/SHOULD/SHOULD NOT/MAY use
> the same
> >
> > hop-by-hop and end-to-end identifiers as the original request.
> >
> > Can anyone point to the position of the standards, or ad hoc standards
> > in this regard?
> 
> RFC6733 Section 3 says "The sender MUST ensure that the Hop-by-Hop
> Identifier in a request is unique on a given connection at any given time". So
> if a different transport connection is used as a result of retransmission, the h-
> b-h id could potentially be different than in the original request. If different
> h-b-h ids were used over the same connection for the same buffered
> request messages that should also work.. I do not recall any text specifically
> prohibiting that. Not that I would find this kind of behaviour good, either..

[LM] The HBH id is rather manage at the Diameter node level than at the connection level. In several places, it is said "locally unique value" without reference to any connection. More specifically, in the relay/proxy case, it is even said "The Hop-by-Hop Identifier in the request is saved and replaced with a  locally unique value.  The source of the request is also saved, which includes the IP address, port, and protocol." which must be interpreted as that only the HBH Id is required to match received answers and information about source of the request is only used for forwarding the answer to the request originator. And this is confirmed by "A Diameter client or proxy MUST match the Hop-by-Hop Identifier in an answer received against the list of pending requests." where the notion of HBH id per connection would not make sense. 
Anyway, in any case the HBH Id in the duplicate request is different from the HBH id of the original request.  Any request must have unique HBH Id as specified in "The Hop-by-Hop Identifier SHOULD be set to a locally unique value" in the section 6.1.2. "Sending a request", that is valid for any request (original or retransmitted).

> 
> RFC6733 Section 3 says "The End-to-End Identifier MUST NOT be modified by
> Diameter agents of any kind." Also "Duplicate requests SHOULD cause the
> same answer to be transmitted (modulo the Hop-by-Hop Identifier field and
> any routing AVPs that may be present), and they MUST NOT affect any state
> that was set when the original request was processed."
> And Section 5.5.4. says "The End-to-End Identifier field in the Diameter
> header along with the Origin-Host AVP MUST be used to identify duplicate
> messages."
> 
> The combination of Origin-Host and e-t-e id must be unique for duplicate
> detection. Now if either one changes the receiver potentially has issues
> determining correctly to which previously seen message the request was a
> retransmission for.
> 
[LM] if either one is change, it is a new request from a Diameter base protocol point of view. There is no way for the server to detect that the request is a retransmitted request, even if the T flag is set in the request. It will not be able to match the retransmitted request to the original one.

> > A secondary question is whether an agent MUST/SHOULD/SHOULD
> NOT/MAY
> >
> > use the same hop-by-hop identifier when forwarding a retransmitted
> > request that it used the
> >
> > first time the message was seen.
> >
> > My sense is that an agent is not required to do so, but may it do so?
> 
> See above.
> 
[LM] When a request is retransmitted by a proxy/relay, the agent is the "originator" of the retransmitted request. The principle given in section 6.1.2 applies here also. The HBH Id in a retransmitted request will be different from the one in the request initially forwarded.

> - JOuni
> 
> >
> > Thanks in advance,
> >
> > David Dolson
> >
> > Senior Software Architect, Sandvine Inc.
> >
> >
> >
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://www.ietf.org/mailman/listinfo/dime
> >
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime

_________________________________________________________________________________________________________________________

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.