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 hannes,
On Sat, Mar 7, 2009 at 12:36 PM, Hannes Tschofenig
<Hannes.Tschofenig at gmx.net> wrote:
> 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.
Not sure to understand your comment. If we define a new App-Id we
won't build the application on Diameter EAP. It will be orthogonal.
What do you mean ?
>
> There is also the question how much you want to say about Mobile IPv6
> bootstrapping in the ERP document.
Yes, Diameter ERP could be used along with Diameter EAP or Diameter
Mobile IPv6.
Regards,
Julien
>
> 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.