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,
>
>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 ?
When you register a new Diameter Application ID then you need to decide
* what Command Codes are needed
* what AVPs are carried inside these Command Codes.
Many past Diameter application designs have answered that question in way
that they said: I re-use an existing application and extend it.
This is essentially what I am suggesting here. You could build your new
application on top of Diameter Mobile IPv6 IKE (which is Diameter EAP +
Mobility AVPs) + your own ERP AVPs.
>>
>> 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.
Ciao
Hannes
>
> 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.