Subject: [Dime] ERP & routing issue, take 2.

From: Sebastien Decugis <[email-masked]>
Date: Wed, 01 Jul 2009 17:32:46 +0900

Hi all,

Since there were some confusions on the motivation for (proposed)
changing the Application-Id in ERP messages, I will try to clarify the
issue, and show what the separate application-id improves.

In the considered scenario, we have two domains (A and B). We have one
NAS, one PROXY, and one SERVER in each domain. (NAS_A, NAS_B, ...). We
have 2 users: USER_A and USER_B, who belong respectively to domains A and B.

I make the following assumptions, when we don't consider ERP (so only
full EAP authentication is possible):

(a) When USER_A connects to NAS_A, a full EAP exchange occurs between
NAS_A and SERVER_A.
(b) When USER_B connects to NAS_A, full EAP exchange between
NAS_A<->PROXY_A<->SERVER_B.

Do we agree so far? Please let me know if these assumptions are false /
too incomplete.

>From this point, we consider addition of ERP to the picture.

Let's consider the situation induced by draft-ietf-dime-erp-00 (i.e. ERP
messages are embedded inside DER/DEA with EAP application).
The well-known benefit case is for (b): PROXY_A supports ERP and
receives rDSRK at the end of the full authentication. It means that
after this first step, (b) exchange becomes:
(br) When USER_B connects to NAS_A, a re-authentication exchange occurs
between NAS_A and PROXY_A.

The routing issue is that the DER message in situation (br) is
*identical* to the DER message in situation (a) in terms of Diameter
routing, but the two messages (a) and (br) must be routed to different
AAA entities, respectively SERVER_A and PROXY_A. The characteristics of
the messages are:
- Application-Id: Diameter EAP application.
- Destination-Realm: A.

If we have a separate Application-Id for DER encapsulating ERP, it
becomes easy to route the messages to the expected entity.

This picture makes a lot of simplifications, but I think it is pertinent
to highlight the issue.
Do you have any comment?

Best regards,
Sebastien.

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

---

From: Yungui Wang <[email-masked]>
Date: Thu, 02 Jul 2009 14:25:48 +0800

Hello

Please see inline... 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Sebastien Decugis
> Sent: Wednesday, July 01, 2009 4:33 PM
> To: [email-masked]
> Subject: [Dime] ERP & routing issue, take 2.
> 
> Hi all,
> 
> Since there were some confusions on the motivation for 
> (proposed) changing the Application-Id in ERP messages, I 
> will try to clarify the issue, and show what the separate 
> application-id improves.
> 
> In the considered scenario, we have two domains (A and B). We 
> have one NAS, one PROXY, and one SERVER in each domain. 
> (NAS_A, NAS_B, ...). We have 2 users: USER_A and USER_B, who 
> belong respectively to domains A and B.
> 
> I make the following assumptions, when we don't consider ERP 
> (so only full EAP authentication is possible):
> 
> (a) When USER_A connects to NAS_A, a full EAP exchange occurs 
> between NAS_A and SERVER_A.
> Do we agree so far? Please let me know if these assumptions 
> are false / too incomplete.
> 
> Let's consider the situation induced by 
> draft-ietf-dime-erp-00 (i.e. ERP messages are embedded inside 
> DER/DEA with EAP application).
> The well-known benefit case is for (b): PROXY_A supports ERP 
> and receives rDSRK at the end of the full authentication. It 
> means that after this first step, (b) exchange becomes:
> (br) When USER_B connects to NAS_A, a re-authentication 
> exchange occurs between NAS_A and PROXY_A.
> 
> *identical* to the DER message in situation (a) in terms of 
> Diameter routing, but the two messages (a) and (br) must be 
> routed to different AAA entities, respectively SERVER_A and 
> PROXY_A. The characteristics of the messages are:

In my mind, for (br), when re-auth request is received, the NAS_A
should firstly locate the USER_B's Diameter Session which is
created during full authentication and has recorded the Proxy_A
(and/or SERVER_B) in the Peer Table. It can then determine the
Proxy_A is next hop. Right? Thanks.

Regards
Yungui

> If we have a separate Application-Id for DER encapsulating 
> ERP, it becomes easy to route the messages to the expected
entity.
> 
> This picture makes a lot of simplifications, but I think it 
> is pertinent to highlight the issue.
> Do you have any comment?
> 
> Best regards,
> Sebastien.
> 
> --
> Sebastien Decugis
> Research fellow
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
>

---

From: Sebastien Decugis <[email-masked]>
Date: Thu, 02 Jul 2009 15:48:33 +0900

Hello Yungui,

> Proxy_A is next hop. Right? Thanks.
Are you talking about Re-Auth-Request messages initiated by the server?
In the scenario, I was rather considering the case where the user
initiates the re-authentication, for example after a handover.
In case of RAR, you are right, the Session-Id, User-Name, and
Destination-Realm may already be known by the NAS, and correct
information set in the message for routing to the Proxy.
In case of handover, the new NAS does not know anything about the
previous authentication of the user, and has no routing entry associated
in its peer table. The identity presented by ERP is KeyName-NAI, which
do not allow to retrieve for example the correct Destination-Realm for
the peer.

Does this make sense?

Best regards,
Sebastien.

---

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

Hello,

 see inline,

> issue, and show what the separate application-id improves.

 Good !

> Do we agree so far? Please let me know if these assumptions are false /

 We agree.

> This picture makes a lot of simplifications, but I think it is pertinent

 Ok, now I see your point. It is more a "internal routing issue" i.e. how
does the PROXY_A knows
if the DER message is to be routed to SERVER_B or locally handled ? Am I
right ?

 Regards,

 Julien

---

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

Hi Julien,

Julien Bournelle a écrit :
>  Ok, now I see your point. It is more a "internal routing issue" i.e.
> how does the PROXY_A knows
> if the DER message is to be routed to SERVER_B or locally handled ? Am
> I right ?
Well, if you consider that the NAS *always* send all the messages to the
proxy_A, then yes it's an internal issue in that proxy.
But if the NAS has to select to send the message to either the local EAP
server, or a local proxy (usually for users belonging to foreign
domains), then the issue is in the NAS, not the proxy.

Sebastien.

---

From: Julien Bournelle <[email-masked]>
Date: Mon, 13 Jul 2009 11:13:22 +0200

Hello,

> proxy_A, then yes it's an internal issue in that proxy.

 But, isn't the NAI set to keyname-NAI which contains the local domain as
"domain" ?

 If this is the case, we don't have anymore the internal issue in the proxy.

 However, this seems cleaner to pass the message to the ERP stack than to
the local EAP stack.

 Other views on this ?

> domains), then the issue is in the NAS, not the proxy.

 but here, this is a different issue. And in this case, having an app-id
doesn't help very much. It only helps if you assume that you have only ONE
local ERP server in the domain. But you also may assume that you have ONE
AAA proxy.

 We have to divide the two issues IMHO.

 Regards,

 Julien

---

From: Sebastien Decugis <[email-masked]>
Date: Tue, 14 Jul 2009 10:28:35 +0900

Hi,

>  But, isn't the NAI set to keyname-NAI which contains the local domain
> as "domain" ?
>  

Sure, but once again, it means that local EAP messages are also sent to
the proxy, not directly to the EAP server. This is unrelated to the
situation I exposed in the opening mail.

>  but here, this is a different issue. And in this case, having an
> app-id doesn't help very much.
No, this *is* the issue for which I opened the thread. An the separate
application-id *does* help separate the messages between ERP proxy(es)
and EAP proxy(es) that do very different processing on the messages, so
it is logical to separate them IMHO.

> It only helps if you assume that you have only ONE local ERP server in
> the domain.
The issue when there are several ERP proxies must be studied, true. A
solution could be that all the keys are always distributed to all the
proxies. We'd need a new command for this purpose.

> But you also may assume that you have ONE AAA proxy.
I don't agree. EAP and ERP proxy are very different in nature. We should
not impose that they are collocated.

>  We have to divide the two issues IMHO.
What is the first issue exactly? I opened the thread only about the
second (routing in the NAS).

Best regards,
Sebastien.

---

From: Julien Bournelle <[email-masked]>
Date: Wed, 15 Jul 2009 11:39:21 +0200

Hello,

> situation I exposed in the opening mail.

the situation that you exposed was that the AAA proxy can't know from the
app-id of the DER message that it is for ERP. This was my understsanding of
your internal routing issue.

> it is logical to separate them IMHO.

 I understand this. I just mentionned below that this could be solved by the
NAI assuming ERP and AAA proxy are colocated.

> proxies. We'd need a new command for this purpose.

I'm not in favor of this. This will overload the network with AAA signalling
which is undesirable.

> second (routing in the NAS).

Read the thread and you'll find the two issues that can be separated.

 Regards,

 Julien

---

From: Sebastien Decugis <[email-masked]>
Date: Thu, 16 Jul 2009 10:58:27 +0900

Hi Julien, all,

Julien Bournelle a écrit :
> the situation that you exposed was that the AAA proxy can't know from
> the app-id of the DER message that it is for ERP. This was my
> understsanding of your internal routing issue.
Sorry for the quiproquo, I guess my original text was not so clear then.

"The routing issue is that the DER message in situation (br) is
*identical* to the DER message in situation (a) in terms of Diameter
routing, but the two messages (a) and (br) must be routed to different
AAA entities, respectively SERVER_A and PROXY_A."

I was really talking about the NAS that must route the message either to
the local proxy or local server.
I hope this clarifies.

>  I understand this. I just mentionned below that this could be solved
> by the NAI assuming ERP and AAA proxy are colocated.
(NAI => NAS I suppose)
But again, even if the ERP local server is collocated with the AAA (i.e.
EAP ?) proxy, the NAS still have to choose to send the message to this
proxy or to the local EAP server.

> I'm not in favor of this. This will overload the network with AAA
> signalling which is undesirable.
I also don't like this approach, but I think it must be considered
anyway in the "pros and cons".
Also, I was not sure if this mail from Glen was pointing to that
direction or not:
http://www.ietf.org/mail-archive/web/dime/current/msg03706.html

> Read the thread and you'll find the two issues that can be separated.
I am very stupid, or really need vacation, but I still don't find two
issues here.

Sebastien.

---

From: Julien Bournelle <[email-masked]>
Date: Thu, 16 Jul 2009 11:29:39 +0200

Hello,

> the local proxy or local server.

 no, I thought we agree on the issues but I'm afraid that we don't.

 The routing will be based on the NAI (Network Access identifier) provided
by the terminal. If the realm part corresponds to the domain A, the message
is routed to SERVER_A else to PROXY_A. So what's the issue ?

> > by the NAI assuming ERP and AAA proxy are colocated.

no. NAI

> proxy or to the local EAP server.

it doesn't choose. It performs routing based on the NAI.

> I am very stupid, or really need vacation, but I still don't find two

hmm. Assuming ERP/EAP/AAA are colocated. The terminal has been authenticated
by a NAS.

First Issue: you have multiple local ERP/AAA servers in the visited domain:
how does the new NAS know which one has the keying material ?

Second issue: ERP/EAP/AAA are colocated, the new NAS sends a DER message to
this AAA server. How does the AAA server knows if this DER message is for
EAP processing or ERP processing ?

I'm afraid that we have this "cycling" discussion because architecture is
not well established...

 Hope this clarifies,

 Regards,

 Julien

---

From: Sebastien Decugis <[email-masked]>
Date: Fri, 17 Jul 2009 10:25:45 +0900

Hi Julien,

Julien Bournelle a écrit :
>  The routing will be based on the NAI (Network Access identifier)
> provided by the terminal. If the realm part corresponds to the domain
> A, the message is routed to SERVER_A else to PROXY_A. So what's the
> issue ?

Ok, now I feel we are moving forward :)

The issue is that with ERP, the realm part of the NAI is domain A, but
the message must be routed to the proxy_A, not the server_A! which
basically does not happen with the behavior you describe.

And that is the routing issue I was talking about in the initial mail of
this thread. :)

Do we agree now on this ?

>     > by the NAI assuming ERP and AAA proxy are colocated.
Ok, sorry. I read too quickly, now I understand.
> it doesn't choose. It performs routing based on the NAI.
I totally agree. And this is the reason for the issue (cause we don't
want to change this behavior).

>  
> hmm. Assuming ERP/EAP/AAA are colocated. The terminal has been
> authenticated by a NAS.
>
> First Issue: you have multiple local ERP/AAA servers in the visited
> domain: how does the new NAS know which one has the keying material ?
Oh, OK, sorry! I thought this issue was ruled out. I totally agree that
this is an issue that must be solved. Anyway I think we agreed it is not
related to the new app-id discussion. I propose we have a different
thread to handle this issue : case of several ER servers in the domain,
with only one bootstrapped for the peer.

> Second issue: ERP/EAP/AAA are colocated, the new NAS sends a DER
> message to this AAA server. How does the AAA server knows if this DER
> message is for EAP processing or ERP processing ?
I was not aware of this issue. By simply looking at the EAP content (EAP
code), or matching the user name with either user table or key cache, it
should be easy to retrieve the correct application, IMHO. The
application ID purpose was not for internal routing inside a peer (at
least not in my initial idea), but for routing in the Diameter network.
I hope it is now clarified from the first answer in this mail?

> I'm afraid that we have this "cycling" discussion because architecture
> is not well established...
Hmmm yes it is possible :) But I still don't see what could clarify it...

Best regards,
Sebastien.

---

From: Julien Bournelle <[email-masked]>
Date: Fri, 17 Jul 2009 11:24:22 +0200

hello,

> Do we agree now on this ?

If PROXY_A and SERVER_A are not collocated and PROXY_A is collocated with
the ERP server, yes, we have an issue.

If the SERVER_A is collocated with the ERP server, we don't have the issue !
:)

The issue would be: how does the SERVER_A receives from PROXY_A the ERP
stuff ?

> <snip>

> with only one bootstrapped for the peer.

Yes we agree. This is an issue and App-Id doesn't help.

> I hope it is now clarified from the first answer in this mail?

App-Id is also used in a internal AAA server to pass the message to the
correct Application. As you know, the same AAA server with a Diameter Base
Protocol stack could implement different Diameter Application on top of the
Base Protocol.

Finally, for this reason, I tend to think that having a App-Id for ERP would
be beneficial to avoid overload the EAP Application.

> Hmmm yes it is possible :) But I still don't see what could clarify it...

For example, does the local ERP server is colocated within local AAA/EAP
server or in the local AAA/EAP proxy ?

 Regards,

 Julien

---

From: Sebastien Decugis <[email-masked]>
Date: Sat, 18 Jul 2009 20:52:20 +0900

Hi,

> If PROXY_A and SERVER_A are not collocated and PROXY_A is collocated
> with the ERP server, yes, we have an issue.
>
> If the SERVER_A is collocated with the ERP server, we don't have the
> issue ! :)
>
> The issue would be: how does the SERVER_A receives from PROXY_A the
> ERP stuff ?
Yes, now we are speaking of the same thing :)
I had not considered so far that ERP server could be collocated with the
EAP server, sorry! It would eliminate the routing issue(s) without the
need for a new Application ID, as you mention.
I personally prefer the separation as a new application, that allows
more flexibility anyway (not forcing the collocaiton of the servers, and
surcharge of the machine).

> App-Id is also used in a internal AAA server to pass the message to
> the correct Application.
I guess this point is purely implementation-dependant, but I agree that
a separate App ID is a great help for the implementors :)

> As you know, the same AAA server with a Diameter Base Protocol stack
> could implement different Diameter Application on top of the Base
> Protocol.
>
> Finally, for this reason, I tend to think that having a App-Id for ERP
> would be beneficial to avoid overload the EAP Application.
Yes :) And also avoid overload of the box, not forcing the collocation
for those who want to separate the EAP and ERP servers.

> For example, does the local ERP server is colocated within local
> AAA/EAP server or in the local AAA/EAP proxy ?
True :) I always assumed it was a separate entity so far (from my
comprehension of ERP). But if a constraint is added that it is
collocated with one of these entities, it is true that it will influence
the design of Diameter ERP, and should be decided before going further
in Diameter ERP.
Of course, if Diameter ERP is able to accomodate ERP server as a
completely separate entity, it is very easy to collocate it with
something else later...

We should probably bring this discussion once again in the HOKEY
mailing-list?

Best regards,
Sebastien.