Re: [Dime] New draft for Diameter ERP: poll for adoption

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

Hello Julien,

Please find my answers inline.

> >   This document specifies how Diameter is used to carry the re-
> >   authentication exchange (second step).  For this purpose, we define a
> >   new Application Id for ERP, and re-use the Diameter EAP commands
> >   (DER/DEA).
>
> We need a justification here.
Do you mean a justification for defining a new application ID?

> >   We also discuss the key distribution (first step, bootstrapping) and
> >   propose some solutions for different architectures.  Anyway,
> >   implementors are free to choose a different mechanism for key
> >   distribution, as for example using RADIUS [I-D.ietf-hokey-key-mgm].
>
>  Rafa sent an email on this draft and I agree with him i.e. the draft
> should
> not mention RADIUS, only AAA.
I also agree with this proposed change.
If the referenced draft is updated, then this sentence will have to be
rewritten accordingly, for example as:
"We also discuss the key distribution (first step, bootstrapping) and
propose some solutions for different architectures, following the
principles of [I-D.ietf-hokey-key-mgm]. Anyway,
implementors are free to choose a different mechanism for key
distribution."

Of course, we might choose to restrict the choice on the key
distribution mechanism if people think it is better.

> >   This simplifies the routing of Diameter messages to the
> >   appropriate server, and allows more flexibility in the deployment of
> >   ERP.
>
>  in which scenario does it simplify the routing process ? in case of
> HO to a new authenticator ?
>  If this is the case, I don't really understand how it solves the
> problem because we may have deployed
> 2 ERPs servers.
It was presented during Virtual Interim meeting last February. You can
still find the slides there:
http://trac.tools.ietf.org/wg/dime/trac/attachment/wiki/ConferenceBridge/diameter-erp.pdf
The advantages of a separate Diameter application ID are highlighted in
slide #8.

> >   The scope of previous documents ([I-D.ietf-dime-erp] and
> >   [I-D.wu-dime-local-keytran]) was focused on the bootstrapping of the
> >   mechanism. 
>
>  this is not really true. The goal of our document was to define how
> to use Diameter
> for ERP for bootstrapping and reauthentication.
That is right, and I simplified too much the phrasing in the new draft,
sorry. The general guidelines are exposed in the "Protocol overview"
section. Anyway, there is no consideration about the message routing and
Diameter deployment. This is what I wanted to express. For example,
after a first re-authentication, the message is sent with local
Destination-Realm and EAP application, but it must reach the ER local
server. I know that this was in the scope of the document (and in the
todo-list), but it was just missing in the current version.

Anyway, if this new design for Diameter ERP is to be accepted, this
section would disappear when the document becomes the WG document.

> >  In particular, these documents did not consider the
> >   routing of Diameter message for re-authentication exchanges (ERP
> >   exchange, and also [RFC4187] for the second document).  By re-using
> >   the Diameter EAP application, they create implicit constraints on
> >   routing of messages that cannot be met by standard Diameter routing
> >   algorithm, as defined in the Diameter Base Protocol [RFC3588].
> >
> >   A separate Diameter application solves this routing issue, and can
> >   also allow the authenticator to dynamically discover if the local
> >   domain supports re-authentication or not.
>
>  I think that it is important to highlight what was the issue and how the
> Application-Id solve it. I don't think that we can go in this new
> direction
> without a clear understanding of the issue and of course of the proposed
> solution.
>
>  So, could you send an email explaining the Issue and the proposed
> solution ?
Do the slides of the Interim meeting answer your questions? Otherwise, I
can try to re-summarize all the discussion in a new mail if needed. I
thought that the routing issue was already accepted, but I realize now
that it does not seem to be the case...
Do you think this discussion should be written in the draft? I was not
sure if the RFC(-to-be) is a right place for design discussions...

Best regards,
Sebastien.

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