Re: [Dime] Diameter ERP

[Qin Wu <sunseawq at huawei.com>]

Hi, Sebastien:
----- Original Message ----- 
From: "Sebastien Decugis" <sdecugis at nict.go.jp>
To: "Qin Wu" <sunseawq at huawei.com>
Cc: <dime at ietf.org>
Sent: Friday, October 16, 2009 11:10 AM
Subject: Re: [Dime] Diameter ERP


> Hi Qin, all,
> 
> Thank you for your comments. Please see my answers inline.
> 
>>> - do we use Diameter ERP (alone) to support re-authentication of the
>>> peer after a handover, or do we mandate the use of a mobility
>>> application (such as MIP6) in that case -- this mobility application
>>> could use Diameter ERP as an optimization.
>>>     
>>
>> [Qin]:  In my understanding, Diameter ERP is not mobility protocol but can reuse the similar mechanism specified in  the mobility application, e.g., Diameter user session mangement ,as described in the section 4.1 of RFC4004, the different sessions can be correlated with the Acct-Multi-Session-Id AVP like. 
>>
>> Therefore the similar mechanism(i.e.,user Session correlation) can also be adopted, i.e., each time the peer  moves to the new NAS, the session-Id created from the new NAS will be  correlated with the user name or Acct-Multi-Session-Id corresponding to this given peer.
>>   
> Ok, so you are suggesting that we should "copy" the mechanism from
> RFC4004 in Diameter ERP, is that right ? In that case are we assuming
> that the (mobile) peer is not using a mobility protocol, and just
> achieving re-authentication but apart from this it is equivalent to a
> plain EAP authentication? What happens if the peer is using a mobility
> protocol (which seems reasonable for a mobile peer) ? Is there no
> conflict or at least duplicates between the ERP and the MIP applications
> in that case?

[Qin]: In the RFC4004, the Diameter user session and the Layer 3 mobility session associated 
with MIP application are not the same thing,  and ERP may borrow the similar mechanism as  
user session management described in the RFC 4004, therefore there is no conflict between ERP 
and the MIP application.

>>> - in case the home domain contains several EAP servers, how does ERP
>>> mechanism find the one that possess the EMSK for a given peer ?
>>>     
>>
>> [Qin]: Isn't EMSKname used to distinguish different EAP servers in the same home domain?
>>   
> Not that I know of... The EMSKname is made of a plain hashed value (no
> indication of server) and the domain name. If we want to use the
> EMSKname for routing, I think we would need a central entity that
> collects all EMSK (at least EMSKnames) from all EAP servers in the
> realm, and routes the messages to the correct servers.

[Qin]: It seems not efficient way for message routing. How about Redirection mechanism, i.e.,
one EAP server possessing no EMSK can redirect the message to the EAP server possessing EMSK.
It seems more efficient than the way you suggest.

>> If EMSKname can not be used to do this, I think ERP/DER messages can be advertised to all the EAP 
>> servers in the home domain, the first EAP server who responds will be viewed as the EAP server that
>>  possess the EMSK for a given peer. Is it right?
>>   
> There is no broadcast mechanism in Diameter (afaik), and going through
> all the servers in sequence seems not efficient to me.

[Qin]: I agree.

> I believe a solution is to store the information about the server (that
> is known during the initial EAP exchange) and then use this information
> when ERP is started. But I am not sure in which location the information
> should be stored, NAS or ER server...

[Qin]: What I prefer is the information can be downloaded at the NAS. And then
the peer can obtain this information directly or indirectly from the NAS.

> Thank you for proposing a solution anyway :) I hope other people can
> also suggest different approaches, or at least comment on the already
> proposed ones.
> 
> Best regards,
> Sebastien.
> 
> -- 
> Sebastien Decugis
> Research fellow
> Network Architecture Group
> NICT (nict.go.jp)
>