Re: [Dime] Diameter ERP
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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?

>> - 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.

> 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.

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...

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)


Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.