[Dime] RE : Re: Question regarding diameter session

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 <ajoshi@definitionnetworks.com> 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

> -----Message d'origine-----
> De : DiME [mailto:dime-bounces at ietf.org<http://ietf.org>] De la part de Ivan Skytte Jørgensen
> Envoyé : jeudi 29 juin 2017 11:21
> À : dime at ietf.org<http://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<http://ietf.org>
> https://www.ietf.org/mailman/listinfo/dime

On Thu, Jun 29, 2017 at 1:15 PM, Ajinkya Joshi <ajoshi@definitionnetworks.com<mailto:ajoshi@definitionnetworks.com>> 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

_________________________________________________________________________________________________________________________

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.