Subject: Re: [Dime] ERP/Routing Issue ?

From: Sebastien Decugis <[email-masked]>
Date: Wed, 01 Jul 2009 16:59:59 +0900

Hi Julien,

Sorry for late answer.

>  Before going further, can we agree on this ?
I agree that we have an issue if several Diameter proxies provide ERP
functions in the local domain. We will have to study this situation. I
am not too sure if this is a question of ERP architecture, or if it is
Diameter specific, anyway. It might be worth asking HOKEY group for
advice on this case.

Anyway, this issue is not the motivation for changing the application-id
of ERP-encapsulated messages. I will open a different thread to present
the issue that motivated this change, in my opinion.

Best regards,
Sebastien.

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)

---

From: Qin Wu <[email-masked]>
Date: Thu, 02 Jul 2009 11:28:24 +0800

Hi, Sebastien and Julien:
It seems this issue is not specific to ERP. Suppose serveral Diameter proxies are located in the visited domain,
Full EAP authentication has to face the same problems. To my knowledge, Decorated NAI can be used to resolve 
this kind of issues. Am I right?

Regards!
-Qin
----- Original Message ----- 
From: "Sebastien Decugis" <[email-masked]>
To: "Julien Bournelle" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, July 01, 2009 3:59 PM
Subject: Re: [Dime] ERP/Routing Issue ?

> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Sebastien Decugis <[email-masked]>
Date: Thu, 02 Jul 2009 13:01:11 +0900

Hi Qin,

> this kind of issues. Am I right?
It is a good point :) I think the implicit assumption is that routing
from a given NAS to a given server is assumed to be stable (i.e. go
through the same proxy) although nothing guarantees this in the current
Diameter protocol. About the end server, there is no problem since
Destination-Host is provided after the first message to ensure later
messages are sent to the same server. There is no such facility for
Proxy(ies), as far as I know.

As for decorated NAI, I think it is an issue under consideration
currently. Diameter base protocol does not support decorated NAI. You
might want to check draft-ietf-dime-nai-routing-02 for more information.

I can see an obvious solution to the problem : if we have several
entities that act as a given application Proxy in a domain, these
entities can be synchronized by some mean (for example using a common
database) so that they can be used interchangeably. But I would be
interested to know if other possibilities / deployments exist.

Best regards,
Sebastien.

---

From: Tom Taylor <[email-masked]>
Date: Thu, 02 Jul 2009 00:26:09 -0400

Well, as I said way back when, explicit routing would solve it. We will be 
bringing in a draft shortly.

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 2 Jul 2009 12:45:52 +0700

...

> interested to know if other possibilities / deployments exist.

This should be the main purpose of the Diameter ERP application, the other
being explicit bootstrapping, neither of which require any interaction w/the
HAAA.

...

---

From: Julien Bournelle <[email-masked]>
Date: Thu, 2 Jul 2009 12:49:45 +0200

Hello,

On Thu, Jul 2, 2009 at 5:28 AM, Qin Wu <[email-masked]> wrote:

> It seems this issue is not specific to ERP. Suppose serveral Diameter
> proxies are located in the visited domain,

Yes this is not specific to ERP. But I thought it was the implicit reason to
have a new Diameter App-ID for ERP.

> this kind of issues. Am I right?

 how ?

 regards,

 Julien

---

From: Julien Bournelle <[email-masked]>
Date: Thu, 2 Jul 2009 12:53:11 +0200

Hello,

> Proxy(ies), as far as I know.

 I thought a given NAS will continue to send and receive Diameter message
from the same AAA proxy for a current Diameter Session. Am I wrong ?

 For me, the issue was more when you have a HO to a new NAS. The new NAS
can't know which AAA proxy/AAA server was used by the previous NAS for
a current user.

 Regards,

 Julien

---

From: Qin Wu <[email-masked]>
Date: Fri, 03 Jul 2009 12:12:39 +0800

Hi, Julien:
  ----- Original Message ----- 
  From: Julien Bournelle 
  To: Qin Wu 
  Cc: Sebastien Decugis ; [email-masked] 
  Sent: Thursday, July 02, 2009 6:49 PM
  Subject: Re: [Dime] ERP/Routing Issue ?

  Hello,

  Yes this is not specific to ERP. But I thought it was the implicit reason to have a new Diameter App-ID for ERP. 
   
  [Qin]: 
  I think how routing works when several Diameter proxys and NASs locate in the same visited realm 
    is one generic issue. Even there is no handover/roaming happening, the host still face to choose right 
  proxy in the visited realm. Decorated NAI can be one of candiate mechanism to resolve this problems. However I am a ittle doubt
  when we have several Diameter Proxys in the visited domain, why the AAA packet should go through the given Diameter proxy?
  If destination of AAA packet is home AAA server ,it seems we don't care which Diameter proxy the AAA packet go through if the home AAA realm is reachable? we can choose one default Diameter proxy to route the AAA packet to the given home AAA server.

   how ?
  [Qin]:
  The Host MAY use decorated NAI to influence the routing choice of the next AAA hop when the home AAA realm is only reachable via another mediating realm (e.g., a visited Diameter Proxy).  For example, Host uses a normal NAI (i.e., user-name@homedomain name) as the AAA packets can be directly routed to the AAA server in the home realm. Whereas, Host needs to construct a decorated NAI (e.g., home domain name!user-name @proxy1 domain name) as the AAA packets cannot directly be routed to the home AAA.  With the decorated NAI, the AAA packeted will be firstly routed to the proxy1 and then proxy1 modify the decorated NAI into user-name@homedomain name, and forward the AAA packet to the given home AAA server based on the modified NAI.

   regards,

   Julien

    Regards!
    -Qin

---

From: Julien Bournelle <[email-masked]>
Date: Fri, 3 Jul 2009 10:37:47 +0200

Hello,

 see inline,

On Fri, Jul 3, 2009 at 6:12 AM, Qin Wu <[email-masked]> wrote:

> *From:* Julien Bournelle <[email-masked]>
> *To:* Qin Wu <[email-masked]>
> *Cc:* Sebastien Decugis <[email-masked]> ; [email-masked]
> *Sent:* Thursday, July 02, 2009 6:49 PM
> *Subject:* Re: [Dime] ERP/Routing Issue ?
>
> Hello,
>
> proxy in the visited realm. Decorated NAI can be one of candiate mechanism
> to resolve this problems. However I am a ittle doubt
> when we have several Diameter Proxys in the visited domain, why the AAA
> packet should go through the given Diameter proxy?
>
>
In the case of ERP, the keying material for the local re-authentication is
in a local AAA server. The new NAS must be able to contact it.

> If destination of AAA packet is home AAA server ,it seems we don't care
> which Diameter proxy the AAA packet go through if the home AAA realm is
> reachable? we can choose one default Diameter proxy to route the AAA packet
> to the given home AAA server.
>
>
>>
> The Host MAY use decorated NAI to influence the routing choice of the next
> AAA hop when the home AAA realm is only reachable via another mediating
> realm (e.g., a visited Diameter Proxy).  For example, Host uses a normal NAI
> (i.e., user-name@homedomain name) as the AAA packets can be directly
> routed to the AAA server in the home realm. Whereas, Host needs to construct
> a decorated NAI (e.g., home domain name!user-name @proxy1 domain name) as
> the AAA packets cannot directly be routed to the home AAA.  With the
> decorated NAI, the AAA packeted will be firstly routed to the proxy1 and
> then proxy1 modify the decorated NAI into user-name@homedomain name,
> and forward the AAA packet to the given home AAA server based on the
> modified NAI.
>
>

 ok. I see.Thus, the host must be aware of the "proxy1.domain.name". I guess
i'll have to read the corresponding draft. However, this won't solve the
issue mentionned below.

 Regards,

 Julien

---

From: Qin Wu <[email-masked]>
Date: Fri, 03 Jul 2009 17:51:17 +0800

Hi, Julien:
  ----- Original Message ----- 
  From: Julien Bournelle 
  To: Qin Wu 
  Cc: Sebastien Decugis ; [email-masked] 
  Sent: Friday, July 03, 2009 4:37 PM
  Subject: Re: [Dime] ERP/Routing Issue ?

  Hello,

  Â see inline,

    Hi, Julien:
      ----- Original Message ----- 
      From: Julien Bournelle 
      To: Qin Wu 
      Cc: Sebastien Decugis ; [email-masked] 
      Sent: Thursday, July 02, 2009 6:49 PM
      Subject: Re: [Dime] ERP/Routing Issue ?

      Hello,

      Yes this is not specific to ERP. But I thought it was the implicit reason to have a new Diameter App-ID for ERP. 
      Â 
      [Qin]: 
      I think how routing works when several Diameter proxys and NASsÂ locate in the same visited realm 
      Â  is one generic issue. Even there is no handover/roaming happening, the host still face to choose right 
      proxy in the visited realm.Â Decorated NAI can be one of candiate mechanism to resolve this problems. However I am a ittle doubt
      when we have several Diameter Proxys in the visited domain, why the AAA packet should go through the given Diameter proxy?

  In the case of ERP, the keying material for the local re-authentication is in a local AAA server. The new NAS must be able to contact it.

  [Qin]:In the case of ERP,If the Host or Peer know the local AAA server via lower layer mechanisms or ERP, the peer or Host 
  can contact with the correct local AAA server, I think. In this way,NAS does not need to contact with the  local AAA server directly.
  On the other hand,  If the Peer or Host can not know the local AAA server, the NAS should be able to contact the right local AAA server instead, In this case, we may choose to define new application Id to distinguish routing to the local ER server from routing to the normal AAA proxy.

  Â 
      Â 

      Â how ?
      [Qin]:
      The Host MAY use decorated NAI to influence the routing choice of the next AAA hop when the home AAA realm is only reachable via another mediating realm (e.g., a visited Diameter Proxy).Â  For example, Host uses a normal NAI (i.e., user-name@homedomain name) as the AAA packets can be directly routed to the AAA server in the home realm. Whereas, Host needs to construct a decorated NAI (e.g., home domain name!user-name @proxy1 domain name) as the AAA packets cannot directly be routed to the home AAA. Â With the decorated NAI, the AAA packeted will be firstly routed to the proxy1 and then proxy1 modify the decorated NAI into user-name@homedomainÂ name, andÂ forward the AAA packet to theÂ given home AAA server based on the modified NAI.

  Â ok. I see.Thus, the host must be aware of the "proxy1.domain.name". I guess i'll have to read the corresponding draft. However, this won't solve the issue mentionned below.
  [Qin]: Right, the presumption is the host know the local domain name, however if the host does not know the local domain name, other possibility or solution is needed.

  Â Regards,

  Â Julien
  Â 

      Â regards,

      Â Julien
      Â 

        Regards!
        -Qin

        ----- Original Message -----
        From: "Sebastien Decugis" <[email-masked]>
        To: "Julien Bournelle" <[email-masked]>
        Cc: <[email-masked]>
        Sent: Wednesday, July 01, 2009 3:59 PM
        Subject: Re: [Dime] ERP/Routing Issue ?

        > Hi Julien,
        >
        > Sorry for late answer.
        >
        >> Â Before going further, can we agree on this ?

---

From: Sebastien Decugis <[email-masked]>
Date: Tue, 07 Jul 2009 10:18:03 +0900

Hi Julien, all,
> from the same AAA proxy for a current Diameter Session. Am I wrong ?
I don't think there is such guarantee in Diameter (but there is usually
no reason for the routing table to change during a session). On the
contrary, with failover / failback mechanism, it is clearly stated that
the route may change during a session. Even after a redirect indication
with Redirect-Host-Usage AVP set to ALL_SESSION, a message of the
session might still be sent to another node as far as I understand,
although this is not very clear in the Diameter Base Protocol.

> can't know which AAA proxy/AAA server was used by the previous NAS for
I agree this is an issue.

B.R.,
Sebastien.