Re: [Dime] Question regarding diameter session

[Ivan Skytte Jørgensen <[e-mail]>]

On Friday 14 July 2017 20:29:23 Ajinkya Joshi wrote:
> On Thu, Jun 29, 2017 at 1:15 PM, Ajinkya Joshi <[e-mail]> 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