Subject: [Dime] Comments on draft-ietf-dime-erp-03.txt

From: "Glen Zorn" <[email-masked]>
Date: Wed, 10 Mar 2010 19:28:40 +0700

Section 4 says:
   If there is an ER server in the same domain as the authenticator
   (local domain), Diameter routing MUST

   QUESTION:
      Should this say "SHOULD: instead of "MUST"?

   be configured so that this ERP/DER message reaches this server, even
   if the Destination-Realm is not the local domain.
I wonder what the purpose of this paragraph might be: why would it be
necessary to configure Diameter routing at all?  Actually, it seems like
this passage could break the ERP app, since the very next paragraph says
that the message should be routed to the bootstrapped ER server in the
re-authentication case.  This seems like the correct behavior, so why modify
it?

Section 4 says:
   When an ER server receives the ERP/DER message, it searches its local
   database for a root key

   FFS:
      and authorization state?
There seems to be some confusion here: an ER server will _never_ receive an
ERP/DER message, since that is a _Diameter_ message, not an EAP message.
Actually, the confusion starts in the Introduction: "a new Diameter ERP
application to transport ERP messages between an ER authenticator and the ER
server".  "Authenticator" is a technical term & refers to an EAP protocol
entity, not a Diameter entity, so how can send Diameter messages?  Clearing
up this confusion might go a long way toward making an acceptable
specification.

---

From: Tina TSOU <[email-masked]>
Date: Thu, 11 Mar 2010 11:01:04 +0800

B. R.
Tina
http://tinatsou.weebly.com/contact.html

----- Original Message ----- 
From: "Glen Zorn" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, March 10, 2010 8:28 PM
Subject: [Dime] Comments on draft-ietf-dime-erp-03.txt

> up this confusion might go a long way toward making an acceptable
True. We need to work it out. Perhaps we have to separate the logical 
functional entity for EAP stuff, and the roles of Diameter stuff.
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Qin Wu <[email-masked]>
Date: Thu, 11 Mar 2010 12:17:39 +0800

> re-authentication case.  This seems like the correct behavior, so why modify
 
[Qin]: Not sure the ER server can terminate the ERP/DER message based on *Diameter ERP application*, 
when the Destination-Realm of the message received from the peer is not the local domain.
In my understanding, Normally Destination-Realm or Realm part of NAI is chosen by the peer and determine 
how the Diameter message is routed. Maybe the destination-Realm can be changed by the Diameter intermediate node.
But the only example I can image is Dedicated NAI is used, the Diameter proxy in the visited realm can replace the
destination-realm of message with home realm name rather than vistited realm name or local realm name.
What am I missing?

---

From: Qin Wu <[email-masked]>
Date: Thu, 11 Mar 2010 14:20:45 +0800

>   When an ER server receives the ERP/DER message, it searches its local

[Qin]: I guess we talk this before as one of open issue. Seems authorization attributes 
is missing, such as 
1.how the service type and Authorization-Lifetime is configured, 
2.how to verify the local ER server is authorized to advertise the domain name, 
3.how to authorize those users for ERP service.
On the other hand, we should decouple authorization with authentication.

> up this confusion might go a long way toward making an acceptable

[Qin]: Is it a big issue?

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 11 Mar 2010 14:23:54 +0700

Qin Wu [mailto:[email-masked]] writes:

...

> [Qin]: Is it a big issue?

Yes.

---

From: Sebastien Decugis <[email-masked]>
Date: Tue, 16 Mar 2010 17:00:54 +0900

Hi, sorry for late reply.

Preliminary question: what is "Network Working Group" ?

> necessary to configure Diameter routing at all?

It is necessary to configure it in the case of an explicit bootstrapping
request, since the NAI contains the home server, but we want to
bootstrap the local server (if any). In any other case, there should be
no conflict : default Diameter routing would send the message to this
local ER server anyway. If we do not configure the routing explicitly,
the message will go to the home domain, and might not pass through the
local ER server. In such case, we loose the benefit of this local server.

> up this confusion might go a long way toward making an acceptable

No you mean that we have to define yet *another* protocol to transport
the ERP message between a Diameter entity (that receives the Diameter
ERP request) and the ER server ? Seems like recursive to me if we don't
accept that the ER server *has* to talk "Diameter" as well... I will be
glad to discuss this further in Anaheim.

About the term "authenticator", I confess it is unclear to me what the
difference is between all the terminology for this entity (the one that
actually decides if the peer gets access or not, and generates the
Diameter EAP request in full EAP authentication scenario). Is "NAS" better?

Best regards,
Sebastien.

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