Re: [Dime] DiME ERP: new Application ID or not ? (non-roaming case)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Dime] DiME ERP: new Application ID or not ? (non-roaming case)
Hi Julien,
>hi hannes,
>
> see inline,
>
>On Wed, Mar 4, 2009 at 9:14 AM, Hannes Tschofenig
><Hannes.Tschofenig at gmx.net> wrote:
>> Hi Julien,
>>
>> When we discussed this at the phone conference call (and the
>> discussion is also captured in the meeting minutes) then I thought
>> that the conclusion was to define a new Diameter application
>for this exchange:
>>
>>
>> Peer Authenticator Server
>> ==== ============= ======
>>
>> [<-- EAP-Initiate/ -----
>> Re-auth-Start]
>> [<-- EAP-Request/ ------
>> Identity]
>>
>>
>> ---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ---------->
>> Re-auth/ Re-auth/
>> [Bootstrap] [Bootstrap])
>>
>> <--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/---------
>> Re-auth/ Re-auth/
>> [Bootstrap] [Bootstrap])
>>
>> Note: [] brackets indicate optionality.
>>
>> Figure 2: ERP Exchange
>>
>> (The server in the figure above is the HOKEY server, a dedicated
>> entity.)
>>
>>
>> The initial EAP authentication is left untouched and, as Glen
>> explained us, there is the assumption that the AAA entities work
>> together with the HOKEY servers in a non-standardized way.
>To me that sounded like a good plan.
>>
>> Does this make any sense?
>
> Taking into accounts that we have one app-id for Diameter EAP
>(I would say NASREQ-EAP) AND soon another app-id for Diameter
>MIP6 (which also use EAP for authentication). It certainly
>make sense to not reuse the same App-ID for ERP if we want to
>use ERP for the mip6 case.
You are pointing to some of the challenges we had during the Diameter extensibility discussions.
With Diameter Mobile IPv6 you are referring to the HA<->AAA server interaction. If you want to cover that case as well and you would like to ensure that messages are correctly understood and correctly routed then you need to define an application that does all these different things. If you are OK with optional parts then you can just define your application and allow other AVPs, namely those from the Diameter Mobility stuff to get included.
Ciao
Hannes
>
> Let's see if others have opinion.
>
> Regards,
>
> Julien
>
>>
>>
>> The non-HOKEY expert
>> Hannes
>>
>> PS: I never said that this is specific document is going to
>be trivial
>> :-)
>>
>>>-----Original Message-----
>>>From: dime-bounces at ietf.org [mailto:dime-bounces at ietf.org] On Behalf
>>>Of Julien Bournelle
>>>Sent: 04 March, 2009 09:05
>>>To: dime at ietf.org
>>>Subject: [Dime] DiME ERP: new Application ID or not ?
>>>(non-roaming case)
>>>
>>>Hi all,
>>>
>>> we try to solve the issue concerning the need for a new
>App-Id or not.
>>>
>>> The ERP protocol (RFC 5296) is to be used along with EAP. It
>>>basically defines two new EAP codes and uses keying material derived
>>>from a first EAP authentication.
>>>
>>> To start the discussion, let's take the non-roaming case.
>>>
>>> In non-roaming, we have first an EAP authentication using Diameter
>>>EAP.
>>> Then, for reauthentication using ERP, we have two messages
>>>(Request/Response) between NAS and the AAA/ERP server carrying EAP
>>>packets
>>>
>>> See (http://tools.ietf.org/html/rfc5296#page-6)
>>>
>>> So, either we reuse the Diameter EAP Application (DER/DEA) or we
>>>define a new Diameter Application.
>>>
>>> If we use a new Diameter Application, a new Diameter
>session will be
>>>created and eventually a new Diameter server will be reached. What
>>>bothers me in this case is that we basically perform a
>>>reauthentication for the same session which is primarly
>handled at the
>>>AAA/EAP server. So, i'm wondering what happens concerning
>>>Authorization Lifetime session etc..
>>>
>>> Note that I still don't have strong opinion and I'll be
>glad to hear
>>>opinions from others.
>>>
>>> Regards,
>>>
>>> Julien
>>>_______________________________________________
>>>DiME mailing list
>>>DiME at ietf.org
>>>https://www.ietf.org/mailman/listinfo/dime
>>>
>>
>>
>_______________________________________________
>DiME mailing list
>DiME at ietf.org
>https://www.ietf.org/mailman/listinfo/dime
>
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.