Subject: [Dime] Question on realm validity in answer messages

From: Marco Stura <[email-masked]>
Date: Thu, 8 May 2014 05:44:18 +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.

---

From: Ivan Skytte Jørgensen <[email-masked]>
Date: Thu, 08 May 2014 12:01:53 +0200

> I'm facing the following situation.
[proxy modifies destination-realm ni requests, but doesn't modify origin-realm in the answer coming back]
...
> Any opinion on this scenario?

I have always found the Origin-Realm AVP of dubious value. Checks on acceptable origins/paths of an answer is done on the Route-Record AVP - not the origin-host/origin-realm.

On the other hand, the proxy in your example modifies the destination-realm in the request, so logically it should modify the origin-realm in the answer.

/isj

---

From: Dave Dolson <[email-masked]>
Date: Thu, 8 May 2014 15:00:17 +0000

(Although I did not contribute to Diameter protocol development, I have been involved in many deep discussions on these types of configurations.)

In my opinion, there are several problems with that deployment:
1. The client and servers should be in different realms. All units in the same realm should be functionally equivalent.
2. Proxies providing a false front for a group of servers add complexity. They are the Diameter equivalent of NAT. If possible, try to have the client talk to the real realm and hosts of the server. It seems the proxy you describe has a bug that it does not reverse-NAT (by analogy) the return packets.
3. It seems the servers should all be in the same realm.

I think the client is right to expect an answer from the realm it sent a request to. Arguably it could be more forgiving...

Here is the more elegant approach:
If all of the servers were in the same realm (say realmX), a conversation would work like this:
- client sends message to Dest-Realm=realmX, (Dest-Host unspecified)
- client realm-routing indicates the proxy can handle it and forwards to proxy.
- based on lack of Dest-Host, proxy realm-routing table determines any of Servers 1-3 (all of realmX) can handle it.
- the proxy selects a host in realmX (e.g., Server1) by any appropriate algorithm
- e.g., Server1 answers the message with Origin-Host=Server1 and Origin-Realm=realmX
- proxy transparently passes the Origin-Host=Server1 and Origin-Realm=realmX
- if client needs to continue the session, the client makes subsequent requests to Dest-Host=Server1 and Dest-Realm=realmX

The beauty of this approach (which I believe the Diameter designers intended) is that the Proxy does not need to keep session state, since the client remembers the host it connected to. You can have multiple proxies for redundancy and they do not require shared session state.

David Dolson
Senior Software Architect
Sandvine

________________________________
From: DiME [[email-masked]] on behalf of Marco Stura [[email-masked]]
Sent: Thursday, May 08, 2014 1:44 AM
To: [email-masked] list
Subject: [Dime] Question on realm validity in answer messages

Dear all,

I’m facing the following situation.

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

BR,
Marco

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 08 May 2014 22:07:54 +0300

Your load balancer is misbehaving. Unfortunately you don't find any 
exact specification language to prohibit the proxy vendor doing this.

- Jouni

5/8/2014 8:44 AM, Marco Stura kirjoitti:
> |----------------------------
> SPrealm--------------------------------------------------|
>
> 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…..
>
> ------------------------------------------------------------------------
>
> 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.
>
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
>

---

From: Marco Stura <[email-masked]>
Date: Fri, 9 May 2014 06:31:44 +0000

Thank you Jouni and all folks that replied.

I wanted to hear opinions without giving mine first. I agree that we cannot find any explicit specification language, but I think this kind of configurations are not really standard and are against the spirit of AAA.

If we think what AAA was invented for, it is all about communicating with the home server that is authoritative to authenticate/authorize the user. The home server shall match the user's home realm.  If we look at the definition of realm in RFC 6733:

Realm

      The string in the NAI that immediately follows the '@' character.
      NAI realm names are required to be unique and are piggybacked on
      the administration of the DNS namespace.  Diameter makes use of
      the realm, also loosely referred to as domain, to determine
      whether messages can be satisfied locally or whether they must be
      routed or redirected.  In RADIUS, realm names are not necessarily
      piggybacked on the DNS namespace but may be independent of it.

Then further on in the RFC it is said that the ream may be derived from the NAI and then populated in the Destination-Realm. Alternatively one could use other mechanisms in the client to determine what realm is authoritative for the user, but whatever mechanism must not be dictated by the implementation of the server or servers composition, it must be a standard mechanism. Otherwise it will never be possible to implement things like roaming. One example is the NAI, another example is the IMSI derived home realm as defined in 3gpp TS 23.003.

By definition there is only one realm that is authoritative, not many different realms (or domains). In my example the realm that is authoritative for the user is "sprealm", as the user belong to that. Therefore a configuration with servers belonging each to a different realm (none of the realm is actually matching the home realm) it's not what I would call a Diameter compliant implementation, as none of the servers can actually be said to serve the user's home realm. Furthermore, again in the spirit of AAA, the Destination-Realm AVP shall not be changed by agents as per diameter request routing processing defined in section 6.1.

IMHO a Diameter compliant implementation would exactly look as the one described by David, which I report below:

What I described in my original email it's actually an horrible hack of Diameter :-) Do you agree?

BR,
Marco

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: Thursday, May 08, 2014 10:08 PM
To: [email-masked]
Subject: Re: [Dime] Question on realm validity in answer messages

Your load balancer is misbehaving. Unfortunately you don't find any exact specification language to prohibit the proxy vendor doing this.

- Jouni

5/8/2014 8:44 AM, Marco Stura kirjoitti:
> 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.
>
> 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.....
>
> 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.
>
>

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 09 May 2014 10:29:43 +0300

Hi

> I wanted to hear opinions without giving mine first. I agree that we cannot find any explicit specification language, but I think this kind of configurations are not really standard and are against…

There is one thing that kind of assumes that the realm is not to be 
changed. The duplicate detection is based on e-2-e identifier and the 
origin-host. So that thing may get confused if the answer messages are 
from a different realm than the request was sent to.

> What I described in my original email it's actually an horrible hack of Diameter :-) Do you agree?

Yes.