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

[Marco Stura <[e-mail]>]

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:

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

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:[e-mail]] On Behalf Of Jouni Korhonen
Sent: Thursday, May 08, 2014 10:08 PM
To: [e-mail]
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:
> 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.
>
>
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime
>

_______________________________________________
DiME mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dime

________________________________

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.