Re: [Dime] R: Mail regarding draft-ietf-dime-rfc3588bis

Yuval Lifshitz <yuvalif@yahoo.com> Wed, 31 October 2018 08:20 UTC

Return-Path: <yuvalif@yahoo.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 5BDCF130DED for <dime@ietfa.amsl.com>; Wed, 31 Oct 2018 01:20:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com
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 ClfOHHa0xHCf for <dime@ietfa.amsl.com>; Wed, 31 Oct 2018 01:20:53 -0700 (PDT)
Received: from sonic315-22.consmr.mail.ne1.yahoo.com (sonic315-22.consmr.mail.ne1.yahoo.com [66.163.190.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE1EE130DEB for <dime@ietf.org>; Wed, 31 Oct 2018 01:20:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1540974052; bh=H3igYe3EdKeS+FpV119JeABSUck6jNrWguTFItMf8/o=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=G6cQzTj58IF7LsThHQkKj6aYskc5NcCDU/FRT1fe2hT4O1dftflMsvm4W6ezDRU4T802LPefxwUspUwf4exD+6GTKXXm8MNN/6nSqpDLwVgeHRXA2WryzMKFiB77YGwx/+EKa5phTS0clxD5X2GK3BhOikbO1aAh4+VHnst/QJM1HAHxXay40ZHeIEnjZOKwMHBv993Vzk8qLHAWMuShjke/Nr8R1ZvXSZrjUxgUM+87tJ4LVbyjIJi6BSfZfY1iEnFw2fG16aDjXd1dU12FgBpMVsP7q6TM2RIEUGGd1+iDOxZMRBy1t8f5c15Wi+azit95ka5r51kQmECdrUtbUA==
X-YMail-OSG: 571XO64VM1nWAiExjfp6KLy.G3xnxFdnn5fvmXR0GcWVoPdsVWlv6gTQaSJNRC7 IiP3Y_GMwIKO3kdyiUPCwaXF9DW7L7ZXjlBPSX1ObFcT1QQ6OwTULmZyPgQQNn.4L3canjYuBAGJ fwPZDz5cgL_1CAxWTB2sjG2QGnuAANtwi6wNrKmMuh2W172Olz7Lwg.UromOfe3wanZVfOd4R3zM ELHbj07JCentZEAVE7nRm.OAlLorJeGlTK6jTgvlqnmjj4Qc6Y8PcxV.4zcGqy1UsdLWUOzUlhn4 v6ol2tfy90A63uXGIe8B0U3._jRHKqAKT92uc7o5YVmsuqZm7_HxD.lNrqcaVFrQKcqQMpvYqXLp QSxQr_JnSI38kGTZJKIhE0PGm6SaAsXGNvcigsyHH1uoQh2xm3AmyX2CE6O10mF9owLiTAlUcWW5 BoOpsV3Flof14kHHPdSXdBce1.bqeOwkexDIy3qy3aVtt98amPWnAD.fddnsachXI2wJGHTqg6iv YDx3pu34Xy9ZIU7ewVISprNPiyGIFiZzGkQKQeF9yP826imKCNQkq5pG2LVy_ZIIsxu5gw_Boaex 1Y81h1VwWWUaU8Fc._qxukYnhCqLobtZ4B.u1y3AOBOd.Tjqi1aLK9OXXGp_dnr4cnz2YHqtl664 Sxb1AMcSCUNB81zgpKSRuW.g8W7Ku8W19iGQpidNC2I7nIxYqeWMZJwlDYlWV5wFKiUPQFT6OFmF yhAvEbhXSyRaitGe88c3RsBZB.4U2G5xSZbsxawhKeOTna4bafYUdZDuhZfeI6tSTI6WrpwMQ7bi q4xOuoRx6gbLWkQxPZl04x.a3EAHd4rn.HbJagf5_rcxmER8Vye3dMZ6iuJZLLdC6e1a.s6ycRsZ p3.mVmaV8JSX7knaSbvkNLYEwfC0LWsP7afU8kNobrPJ2POqDQThtafZbv5yK_H.fc1QVEdzok8K wQWCEyrbaoPBkLaogUZ7qKVv3UFlbyAzz5ShHi0zdtYFJfZwpGLkjHI_FDYHCe_a2hZNSaCE_71_ RXsAk4438oCNnp_qdTgzYmbFB.Lm2n5w-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.ne1.yahoo.com with HTTP; Wed, 31 Oct 2018 08:20:52 +0000
Received: from bzq-82-81-161-50.red.bezeqint.net (EHLO dhcp-0-211.tlv.redhat.com) ([82.81.161.50]) by smtp408.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 2df02e61759bd04dbdf6265138e15e7d; Wed, 31 Oct 2018 08:20:52 +0000 (UTC)
Date: Wed, 31 Oct 2018 10:20:48 +0200
From: Yuval Lifshitz <yuvalif@yahoo.com>
To: Villa Silvia <Silvia.Villa@italtel.com>
Cc: "dime@ietf.org" <dime@ietf.org>
Message-ID: <20181031082048.GA12198@dhcp-0-211.tlv.redhat.com>
References: <9483df2e03b04080a857b3bee987f434@italtel.com> <1783796887.17665942.1540728405641@mail.yahoo.com> <ec1221a4f2c6434b93f7bdb3600953aa@italtel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <ec1221a4f2c6434b93f7bdb3600953aa@italtel.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/edm16b6TnzGWyW0RmIHG5Og5bsA>
Subject: Re: [Dime] R: Mail regarding draft-ietf-dime-rfc3588bis
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 31 Oct 2018 08:20:56 -0000

While it may be that some servers will allow that (folowing the "Robustness Principle"), the client should not do that.
Note that even in the case that the server don't mind the change in Origin-Host, it is most likely because it ignores it, and will not update the value - either way, this is server specific implementation and not part of the spec.
If the client just reconnected to the server, than the Diameter session should just continue, using the original parameters (including Origin-Host).
If the client went down, and a different client took over, than the client is either expected to start a new session (the common case where the client is stateless) whith a new Origin-Host, or to continue the same session (if the client is stateful) with the old Origin-Host.

Yuval

On Mon, Oct 29, 2018 at 04:23:02PM +0000, Villa Silvia wrote:
> Thank you very much for your answer Yuval.
> 
> Do you think that is allowed to a Diameter Client sending a subsequent AAR for a Session by a different Origin-Host?
> What do you think server will do?
> 
> Let me clarify...
> 
> I have this Diameter Client that opens many Diameter Connections with different Origin-Hosts and the same Origin-Realm.
> 
> Suppose that the Client sends an AAR for a new Session by Diameter-Connection-1 and Origin-Host-1.
> Suppose that the Diameter-Connection-1 will fell and lost.
> It shall be permissible for the Client to send subsequent re-auth for the same Session-Id by a Diameter-Connection-2 and Origin-Host-2?
> The Server is required to update the Destination-Host associated to the Session-Id (like Target Refresh Requests in SIP dialogs)?
> And so all subsequent RAR or ASR will be sent by Server to the Diameter-Connection-2 and Destination-Host-2.
> 
> Thank you again, Yuval.
> 
> Silvia
> 
> 
> Da: Yuval Lifshitz [mailto:yuvalif@yahoo.com]
> Inviato: domenica 28 ottobre 2018 13:07
> A: dime@ietf.org; Villa Silvia <Silvia.Villa@italtel.com>
> Oggetto: Re: [Dime] Mail regarding draft-ietf-dime-rfc3588bis
> 
> Hello Silvia,
> The server is expected to send the RAR to the same host from which the session was initialized (i.e the Destination-Host of the RAR should be the same as the Origin-Host of the AAR).
> 
> There is no requirement, however, to send the RAR on the same Diameter connection that was used to send the AAR. For example, if there was a connectivity issue with the client after the AAR was sent, that was resolved (client reconnected wit the same Diameter identity), and then the server want to send the RAR, it should be allowed to send it over the new connection to the same client (with the correct Destination-Host).
> 
> Another case is where the client is not directly connected to the server (i.e. a Diameter agent sits between them). In such a case the server may use "realm routing" and send the RAR on any Diameter connection that may reach the desired realm. However, even in this case, the Destination-Host of the RAR must be set to the correct Destination-Host, and it is up to the Diameter agent(s) to route the request to the correct client.
> 
> Hope this helps,
> 
> Yuval
> 
> On Friday, October 26, 2018, 3:47:26 p.m. GMT+3, Villa Silvia <Silvia.Villa@italtel.com<mailto:Silvia.Villa@italtel.com>> wrote:
> 
> 
> 
> Hello Diameter experts and funs,
> 
> 
> 
> I have a question on the interpretation of RFC 6733.
> 
> 
> 
> I have a Client Diameter that opens many Diameter Connections with different Origin-Hosts and the same Origin-Realm.
> 
> The Client need to send AAR in session with maintained state to a Server.
> 
> 
> 
> Where a Diameter Server will send requests in session such as RAR or ASR?
> 
> 
> 
> The Destination-Host-AVP must be valued with the Origin-Host-AVP of the AAR sent by the client or a different Destination-Host-AVP can be chosen by realm?
> 
> 
> 
> What would happen if the diameter connection will fell and lost?
> 
> The Diameter Server must/can/cannot choose to send the request to a different Destination-Host-AVP of the same Client Realm?
> 
> 
> 
> I cannot understand where is the limit between protocol rules and custom policy local develop solution.
> 
> 
> 
> Thank you.
> 
> 
> 
> Silvia
> 
> 
> Internet Email Confidentiality Footer ** La presente comunicazione, con le informazioni in essa contenute e ogni documento o file allegato, e' rivolta unicamente alla/e persona/e cui e' indirizzata ed alle altre da questa autorizzata/e a riceverla. Se non siete i destinatari/autorizzati siete avvisati che qualsiasi azione, copia, comunicazione, divulgazione o simili basate sul contenuto di tali informazioni e' vietata e potrebbe essere contro la legge vigente (ad es. art. 616 C.P., D.Lgs n. 196/2003 Codice Privacy, Regolamento Europeo n. 679/2016/GDPR). Se avete ricevuto questa comunicazione per errore, vi preghiamo di darne immediata notizia al mittente e di distruggere il messaggio originale e ogni file allegato senza farne copia alcuna o riprodurne in alcun modo il contenuto. Al link seguente e' disponibile l'informativa Privacy: http://www.italtel.com/it/about/privacy/ ** This e-mail and its attachments are intended for the addressee(s) only and are confidential and/or may contain legally privileged information. If you have received this message by mistake or are not one of the addressees above, you may take no action based on it, and you may not copy or show it to anyone; please reply to this e-mail and point out the error which has occurred. Click here to read your privacy notice: http://www.italtel.com/it/about/privacy/
> _______________________________________________
> DiME mailing list
> DiME@ietf.org<mailto:DiME@ietf.org>
> https://www.ietf.org/mailman/listinfo/dime
> Internet Email Confidentiality Footer ** La presente comunicazione, con le informazioni in essa contenute e ogni documento o file allegato, e' rivolta unicamente alla/e persona/e cui e' indirizzata ed alle altre da questa autorizzata/e a riceverla. Se non siete i destinatari/autorizzati siete avvisati che qualsiasi azione, copia, comunicazione, divulgazione o simili basate sul contenuto di tali informazioni e' vietata e potrebbe essere contro la legge vigente (ad es. art. 616 C.P., D.Lgs n. 196/2003 Codice Privacy, Regolamento Europeo n. 679/2016/GDPR). Se avete ricevuto questa comunicazione per errore, vi preghiamo di darne immediata notizia al mittente e di distruggere il messaggio originale e ogni file allegato senza farne copia alcuna o riprodurne in alcun modo il contenuto. Al link seguente e' disponibile l'informativa Privacy: http://www.italtel.com/it/about/privacy/ ** This e-mail and its attachments are intended for the addressee(s) only and are confidential and/or may contain legally privileged information. If you have received this message by mistake or are not one of the addressees above, you may take no action based on it, and you may not copy or show it to anyone; please reply to this e-mail and point out the error which has occurred. Click here to read your privacy notice: http://www.italtel.com/it/about/privacy/