Re: [Dime] Question regarding diameter session

Ivan Skytte Jørgensen <isj-dime@i1.dk> Fri, 14 July 2017 19:12 UTC

Return-Path: <isj-dime@i1.dk>
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 5E3F41316A8 for <dime@ietfa.amsl.com>; Fri, 14 Jul 2017 12:12:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-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 dJ8rUK1BWPLz for <dime@ietfa.amsl.com>; Fri, 14 Jul 2017 12:12:52 -0700 (PDT)
Received: from i1.dk (55e9f507.rev.dansknet.dk [85.233.245.7]) by ietfa.amsl.com (Postfix) with ESMTP id 45F20131690 for <dime@ietf.org>; Fri, 14 Jul 2017 12:12:50 -0700 (PDT)
Received: from i1.dk (localhost [127.0.0.1]) by i1.dk (Postfix) with ESMTP id BB10585571 for <dime@ietf.org>; Fri, 14 Jul 2017 19:12:49 +0000 (UTC)
Received: from isjsys.localnet (isjsys [10.0.0.2]) by i1.dk (Postfix) with ESMTPA for <dime@ietf.org>; Fri, 14 Jul 2017 19:12:49 +0000 (UTC)
From: Ivan Skytte =?ISO-8859-1?Q?J=F8rgensen?= <isj-dime@i1.dk>
To: dime@ietf.org
Date: Fri, 14 Jul 2017 21:12:49 +0200
Message-ID: <2021427.Za52vkRhto@isjsys>
User-Agent: KMail/4.11.5 (Linux/3.11.10-29-desktop; KDE/4.11.5; x86_64; ; )
In-Reply-To: <CAFUT_s2v_hEMRz-NC0sZhcEnZYqn9-vcnq1wGzkgyF_qekse1Q@mail.gmail.com>
References: <CAFUT_s2os8=BkfGFyBd3W0V+yQ5wiwCibagLxrL8OTKWQ8ZGgA@mail.gmail.com> <CAFUT_s2v_hEMRz-NC0sZhcEnZYqn9-vcnq1wGzkgyF_qekse1Q@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/MhTSZjxA8up-oTSx7A0CShB1wgo>
Subject: Re: [Dime] Question regarding diameter session
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 14 Jul 2017 19:12:54 -0000

On Friday 14 July 2017 20:29:23 Ajinkya Joshi wrote:
> On Thu, Jun 29, 2017 at 1:15 PM, Ajinkya Joshi <ajoshi@definitionnetworks.com> wrote:
> 
> > From the RFC 6733, it is clear that diameter session is identified bases
> > on session-id, which has to be globally unique. Also in section 2.5
> > (Connections vs Sessions), it's clearly mentioned that one connection can
> > be used to multiplex multiple diameter sessions.
> > I have following questions related to diameter session -
> >
> > Is there any implicit correlation between diameter session and
> > origin-host?
> > Does diameter standard allow different requests for the same session to
> > have different origin-host value?
> > Is there any possible problem if the value of Diameter Identity (part of
> > recommended format for session-id) is different from those present in the
> > request (like origin-host/origin-realm)?
> > -----Message d'origine-----
> > De : DiME [mailto:dime-bounces <dime-bounces> at ietf.org] De la part de Ivan Skytte Jørgensen
> > Envoyé : jeudi 29 juin 2017 11:21
> > À : dime at ietf.org
> > Objet : Re: [Dime] Question regarding diameter session
> >
> > On Thursday 29 June 2017 13:15:05 Ajinkya Joshi wrote:
> > > Hello,
> > >
> > > >From the RFC 6733, it is clear that diameter session is identified
> > > >bases on
> > > session-id, which has to be globally unique. Also in section 2.5
> > > (Connections vs Sessions), it's clearly mentioned that one connection
> > > can be used to multiplex multiple diameter sessions.
> > > I have following questions related to diameter session -
> > >
> > > Is there any implicit correlation between diameter session and origin-host?
> >
> > Only what is spelled out in the RFC "The Session-Id MUST begin with the sender's
> > identity [...]"
> 
> [LM] correct.
> 
> >
> > A dubious diameter implementation may decode the session-id extracting what
> > the origin-host might be. But that would be silly since it is already present in the
> > origin-host AVP. Well-behaved diameter implementations treat session-id as an
> > opaque string.
> >
> > > Does diameter standard allow different requests for the same session
> > > to have different origin-host value?
> >
> > Yes, eg RAR and ASR requests will have a typically have an origin-host/realm
> > different from where the session-id was created.
> 
> [LM] if the question was for requests with different origin-host
> received by the same server for the same session, the answer is NO.
> Session related data maintained by a server for a given session are
> bounded to a single Origin-host. As said in the RFC6733,
>   "A session is a
>    logical concept at the application layer that exists between the
>    Diameter client and the Diameter server; it is identified via the
>    Session-Id AVP."
> There is therefore a 1-to-1 relationship between the server and the
> client initiating the session. If a server would accept session
> related messages from different nodes for the same session, it would
> not possible to ensure a consistent management of the session state,
> e.g. node A creating the session, node B terminating the session
> whereas node A is not aware.
> 
> [AJ] What if there is an implementation where client is distributed
> and session state is shared by some means between the various client
> nodes. Each of the client node represents  different diameter host.
> So, how would server behave, if say client node-1 (with diameter host
> name as "n1", which becomes origin-host) initiates a diameter session,
> and different client node say node-2 (with diameter host name as "n2",
> which becomes origin-host) sends some subsequent message for the same
> session (using same session-id)?

I have done something similar in the past (a 3gpp reference point if I remember correctly).
The central component "owning" the session was not diameter-capable. The diameter communication was handled by multiple front-ends. The diameter session id was unique (the front-ends and the central component coordinated and ensured that, as well as the end-to-end-identifier). The front-ends would then lie that they were proxies even though they technically originated the messages. Eg. the upstream OCS would see messages like:

<message from peer frontend1.example.com>
	session-id : backend.example.com;13459781;7569726735
	origin-host : backend.example.com
	route-record : frontend1.example.com

and the upstream OCS would be none the wiser because it could not tell if frontend1.example.com was in fact a proxy or if it was lying. It worked.

But in order to do something like that you have to ensure three things:
1: The diameter session-id must be globally eternally unique. And be the same for the same session.
2: Origin-host + end-to-end-identifier must be unique for at least 4 minutes.
3: Origin-host must be the same as the diameter-identity in the session-id.

There may be other items that system need to synchronize such as cc-request-number value.

So that means you need state synchronization in your distributed system.

The only remaining thing I can think of is that some upstream systems may not like proxied messages at all. I don't know how common that problem is nowadays.


/isj