Re: [Dime] Question regarding diameter session

Hi,

Please see below.

Regards,

Lionel

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

> 
> 
> /isj
> 
> _______________________________________________
> 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.