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)
I also have to add ...
If you define a new Diameter Application ID then you have to decide which
application to use as a baseline. If you look at Section 5.1 of
http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-16.txt then
you see that the Mobile IPv6 specific AVPs are optional in the Command Code
ABNF. Hence, building on EAP is probably not such a bad idea.
There is also the question how much you want to say about Mobile IPv6
bootstrapping in the ERP document.
Ciao
Hannes
>-----Original Message-----
>From: Julien Bournelle [mailto:julien.bournelle at gmail.com]
>Sent: 04 March, 2009 12:03
>To: Hannes Tschofenig
>Cc: dime at ietf.org
>Subject: Re: [Dime] DiME ERP: new Application ID or not ?
>(non-roaming case)
>
>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.
>
> 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
>>>
>>
>>
>
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.