Re: [Dime] Question regarding diameter session

Ajinkya Joshi <ajoshi@definitionnetworks.com> Fri, 14 July 2017 14:59 UTC

Return-Path: <ajoshi@definitionnetworks.com>
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 5957B12F28B for <dime@ietfa.amsl.com>; Fri, 14 Jul 2017 07:59:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=definitionnetworks-com.20150623.gappssmtp.com
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 yRdzJGCt7iT6 for <dime@ietfa.amsl.com>; Fri, 14 Jul 2017 07:59:24 -0700 (PDT)
Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D0B412EB43 for <dime@ietf.org>; Fri, 14 Jul 2017 07:59:24 -0700 (PDT)
Received: by mail-pg0-x22d.google.com with SMTP id j186so46869665pge.2 for <dime@ietf.org>; Fri, 14 Jul 2017 07:59:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=definitionnetworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=qELOHRZMrIQwTDXIBFw2dwAiZP0skAmT9C5Opd4MEBY=; b=mLZnhu0LQY9YdSpSxK5ThVoMCBlkMY2XvnUDn7iYzIrZ3OVOjYjkuNu1OGofQUHCuV THJs4YNrsKGvNYVFRqtScA5PK72op0lQIeBeSXU9MuH00+bb3mwkPdJE+nE8fdmR9GaP wm/adNX6wlc/HA8p5dR3dju4af7wo2U6oEMCPkYS5tgCCj1ZQmfcGEZzgFg5ze7LiOpB eNzW/IkeBBaw/d9pH6pFMlHmyHRh1Vpb59XIbXcggYTeykYqKSltYciWqtIw2+dGSktv dkOtBGz4f2hSl/JjQLkfb6gEYCiDKw3www1+7f92VM6IfIUTA8VB1mVWIm0PBn6hQT8k kPew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=qELOHRZMrIQwTDXIBFw2dwAiZP0skAmT9C5Opd4MEBY=; b=GBlHAzYROT2v4RS7EWHggO5nCQ4WIEEphFHv+8NbnvEn38dLOvuJQXPc3YGNd/wABj ZpP5u9dmEPzSuXxTeW/Lx7iB6Zvv3AlAJBGxek5xidFz9BAt/mzr/Toka/1NWnLJmefa 87ppwVUNfwY7pZLJ2ZFNHlgEX/wGFHdjw+7n/4h4mKaTiJ0x+VYYH8QQRpYBgOMMn2zR zMW49BaRvBiI5XvWRyQGNbliHcgSl2+8hE1UCzcbyb/9vFP4CVQe+bfsxkGinh3KLNw5 7XYS61iGlR2Rfj34RsjHBOnFlkMOMViN0b2P396LYaaJ2ScjANLqOuJBWhVC8KPfw+0z 3csw==
X-Gm-Message-State: AIVw113aKBSX0ZU5oYhWpwG7sJa5hMIkBUS41MYLz+TMKhpHtIs0kUON PcRKZufcYmWovjjJwmwU3OA9pkbJcd+FkBw=
X-Received: by 10.84.176.65 with SMTP id u59mr10370721plb.23.1500044363539; Fri, 14 Jul 2017 07:59:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.153.82 with HTTP; Fri, 14 Jul 2017 07:59:23 -0700 (PDT)
In-Reply-To: <CAFUT_s2os8=BkfGFyBd3W0V+yQ5wiwCibagLxrL8OTKWQ8ZGgA@mail.gmail.com>
References: <CAFUT_s2os8=BkfGFyBd3W0V+yQ5wiwCibagLxrL8OTKWQ8ZGgA@mail.gmail.com>
From: Ajinkya Joshi <ajoshi@definitionnetworks.com>
Date: Fri, 14 Jul 2017 20:29:23 +0530
Message-ID: <CAFUT_s2v_hEMRz-NC0sZhcEnZYqn9-vcnq1wGzkgyF_qekse1Q@mail.gmail.com>
To: dime@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c1196546fb8a80554484b9d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/FNdWednaXUJguLTeVpnSJ0XMUqQ>
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 14:59:26 -0000

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