[Dime] Question on realm validity in answer messages

Marco Stura <mstura@ooredoo.com> Thu, 08 May 2014 05:44 UTC

Return-Path: <mstura@ooredoo.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B021A0239 for <dime@ietfa.amsl.com>; Wed, 7 May 2014 22:44:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.101
X-Spam-Level:
X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 dXXUk9vzbakg for <dime@ietfa.amsl.com>; Wed, 7 May 2014 22:44:43 -0700 (PDT)
Received: from koala.qtel.com.qa (koala.qtel.com.qa [212.77.203.181]) by ietfa.amsl.com (Postfix) with ESMTP id C20EE1A0236 for <dime@ietf.org>; Wed, 7 May 2014 22:44:40 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.97,1009,1389733200"; d="scan'208,217";a="45485827"
Received: from Rock5.qtel.ad.pri ([169.254.1.2]) by SEEMA1.qtel.ad.pri ([172.16.224.85]) with mapi id 14.02.0347.000; Thu, 8 May 2014 08:44:19 +0300
From: Marco Stura <mstura@ooredoo.com>
To: "dime@ietf.org list" <dime@ietf.org>
Thread-Topic: Question on realm validity in answer messages
Thread-Index: Ac9qf1ZFcwDgn1ogQWiJwS5MzXcRlQ==
Date: Thu, 08 May 2014 05:44:18 +0000
Message-ID: <0EFE155B2AF9B44A9537DA67801704F96B3341E2@ROCK5.qtel.ad.pri>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.16.21.53]
x-exclaimer-md-config: e2f59e9d-2ace-4eb8-ad46-dee98c3fdea5
Content-Type: multipart/alternative; boundary="_000_0EFE155B2AF9B44A9537DA67801704F96B3341E2ROCK5qteladpri_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Zzp4uJwXnwwc6iFgsHP5bxwr3fc
Subject: [Dime] Question on realm validity in answer messages
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Thu, 08 May 2014 05:44:47 -0000

Dear all,

I'm facing the following situation.

|---------------------------- SPrealm--------------------------------------------------|

                                                                                   _----------- Server 1(realm a)
                                                                                _
                                                                             _
Client ------------------ Proxy(SPrealm) ---------------- Server 2(realm b)
                                                                            _
                                                                                _
                                                                                   _
                                                                                       ---------- Sever 3 (realm c)


The implementation is such that the Proxy is load balancing by selecting the internal Server where the subscriber data are provisioned, based on user identity.
The Client is sending an application specific authorization request to the Proxy for NAI user@SPrealm, Destination-Realm == SPrealm.
The Proxy selects e.g. Server 2 based on user@SPrealm and send the request there changing the Destination-Realm to realm b.
Server 2 processes the request generates an answer and send it to the Proxy with Origin-Host == server2@realm b, Origin-Realm == realm b.
The Proxy forward the answer to the Client, that receives a successful authorization answer from a realm that is different from the one supposed to serve the user (as in the NAI).
The client terminates the session with STR to Destination-Host == server2@realm b, Destination-Realm == realm b, Termination-Cause == Diameter_bad_answer

The Proxy and the Servers are part of the same implementation, which apparently requires this kind of configuration to work.
In RFC 6733 (or RFC 3388) it is not explicitly stated how to deal with cases where a successful authorization answer is coming from a server located in a different realm than the home realm of the user (as per NAI).
However, to say the least, this configuration is quite bizarre and the client IMHO is right to terminate the session as this behavior may looks to the client like an answer from a malicious node. But I don't remember any discussion on this aspects back at the Diameter protocol development time.....

Any opinion on this scenario?

BR,
Marco





________________________________

The information in this email and any attachments thereto may contain information that is confidential, protected by intellectual property rights, and may be legally privileged. It is intended solely for the addressee(s). Access to this email by anyone else is unauthorized. Any use, disclosure, copying, or distribution of the information contained herein by persons other than the designated addressee is unauthorized and may be unlawful. If you are not the intended recipient, you should delete the message immediately from your system. If you believe that you have received this email in error, please contact the sender. Any views expressed in this email and its attachments are those of the individual sender except where the sender expressly states them to be the views of Ooredoo.