Re: [Dime] Comments on section 3 of new version draft-ietf-dime-erp-01

[Sebastien Decugis <sdecugis at nict.go.jp>]

Hi again again, and inline...

> 3. Assumptions
>
> [Qin]: Since ERP root key can be derived for specific domain, I think
> these root key can also be derived for the same part of the home
> domain as the home EAP server,
> am I right?
I think I don't understand the question... For home domain, the key
derivation is different in ERP: rRK instead of rDSRK.

>
> home EAP server implicitly authorizes the use of ERP within this
> domain.
>
> [Qin]: I am wondering what does the home EAP server base on to
> authorize the use of ERP within
> given domain? Isn't it enough to assume trust relationship between
> local domain and home domain?
I wanted to highlight the implication of deriving a key for ERP. By
providing an ERP root key for a visited domain, the local domain server
implicitly authorizes the use of ERP in that domain. The consequences on
the management of the session and other side effects should be
understood by the home domain before accepting to derive this material.

> [Qin]: s/contained/contains
Hmmm I will try a different phrasing here, the sentence is too
complicated anyway. Thank you for pointing it out.

>
> [Qin]:What does "(recommanded)"? recommended?
Oops that is French-English sorry I will fix it. Yes, I meant
"recommended".
> Is there any missing text here? I am wondering ability to answer
> a DER message can be covered by Diameter operations?
There are two different operations: support to send the rRK/rDSRK in
Diameter message; and support to answer an EAP-Initiate ERP message.
While the first is mandatory, the second is only needed to support
explicit bootstrapping scenario. That is the rationale for the
"(recommended)" notation.

> Allow the new ERP command codes (EAP-Initiate and EAP-Finish) in
> its EAP pass-through mode.
> (optional) Send the EAP-Initiate/Re-Auth-Start message
> [Qin]: I am wondering what's the difference between the first bullet
> and the second bullet?
The EAP-Initiate/Re-Auth-Start message is optionally sent by the NAS to
the *peer* to initiate ERP exchange, as described in RFC5296 (second
bullet). The other messages (from first bullet) are exchanged between
the peer and the server, the NAS is only acting as a passthrough. But
EAP passthrough definition requires that unknown EAP codes messages are
dropped, so the NAS must be changed to allow the ERP codes as well.

> We consider at most one logical ER server entity in a domain. If
> several physical servers are deployed for robustness, a replication
> mechanism must be deployed to synchronize the ERP states (root keys )
> between these servers. This replication mechanism is out of the
> scope of this document. If several ER servers are deployed in the
> domain, we assume that they can be used interchangeably.
> [Qin] Does this mean all the ER server in one domain can be seem as
> one logical ER server?
Yes it is the assumption here in this version of the document. If we
don't have this assumption, we must provide a way to either:
- synchronize explicitly the states between different ER servers inside
one domain.
- ensure that messages belonging to one session are routed to the
appropriate ER server.

Since the primary rationale for having several ER server is robustness,
it is logical to assume that the servers must be synchronized in any
case. Since synchronization of states in Diameter between several
servers is a general issue, it is better not to define a solution only
for ERP application. A new Diameter application could be defined for
this matter, but we don't want to do this inside Diameter ERP. So, all
in all, it is easier to simply assume the servers are synchronized and
can be used interchangeably. Does that make sense?

Best regards,
Sebastien.

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