Subject: Re: [Dime] Question regarding diameter session

From: Ajinkya Joshi <[email-masked]>
Date: Fri, 14 Jul 2017 20:29:23 +0530

I didn't receive the replies on email.
Inline question starting with [AJ]
Copying the responses from archive for reference. ---

Hi,

Please see below.

Regards,

Lionel

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

>
>
> /isj
>
> _______________________________________________
> DiME mailing list
> DiME at ietf.org
> https://www.ietf.org/mailman/listinfo/dime

On Thu, Jun 29, 2017 at 1:15 PM, Ajinkya Joshi <
[email-masked]> 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?
> 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)?
>
> --
> Regards,
> Ajinkya Joshi
>

-- 
Regards,
Ajinkya Joshi

---

From: <[email-masked]>
Date: Fri, 14 Jul 2017 15:47:27 +0000

Hi,

not sure to understand... The use case that you give is exactly the one that I gave to illustrate my answer "No".
The server would either reject or ignore sessions related requests coming from another source.

Lionel

Le 14 juil. 2017 16:59, Ajinkya Joshi <[email-masked]> a écrit :
I didn't receive the replies on email.
Inline question starting with [AJ]
Copying the responses from archive for reference. ---

Hi,

Please see below.

Regards,

Lionel

> De : DiME [mailto:dime-bounces at ietf.org<http://ietf.org>] De la part de Ivan Skytte Jørgensen
> À : dime at ietf.org<http://ietf.org>

[LM] correct.

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

> DiME at ietf.org<http://ietf.org>

On Thu, Jun 29, 2017 at 1:15 PM, Ajinkya Joshi <[email-masked]<mailto:[email-masked]>> 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.

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

--
Regards,
Ajinkya Joshi

--
Regards,
Ajinkya Joshi

_________________________________________________________________________________________________________________________

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.

---

From: Ivan Skytte Jørgensen <[email-masked]>
Date: Fri, 14 Jul 2017 21:12:49 +0200

On Friday 14 July 2017 20:29:23 Ajinkya Joshi wrote:
> On Thu, Jun 29, 2017 at 1:15 PM, Ajinkya Joshi <[email-masked]> wrote:
> 

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