Subject: [Dime] Diameter MIPv6 Bootstrapping: case HA-AAAH

From: Julien Bournelle <[email-masked]>
Date: Thu, 7 Sep 2006 15:28:13 +0200

Hi all,

 from the recent polling, it appears that we agree to define an new
 App-ID for the HA-AAAH case.

 So we'll move forward with this for the draft-ietf-dime-split-00.txt
 document.

 Thanks,

 Julien 

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 07 Sep 2006 09:42:41 -0400

Hi Julien,

I am not sure what level of agreement you mean.

At least I have a concern on the following text in Section 4.2 of 
draft-ietf-dime-mip6-split-00.txt:

"
   However, the protocol
   description requires that the new application needs to copy the
   Diameter messages from the Diameter EAP application.
"

When defining a new application with a new application identifier, if
we define it by copying and modifying Diameter EAP ABNF, it will end
up with permutation problem in a future.  I don't agree with this
specific way of defining a new application id as I already mentioned.

Yoshihiro Ohba

---

From: Julien Bournelle <[email-masked]>
Date: Thu, 7 Sep 2006 16:06:13 +0200

Hi Yoshi,

> I am not sure what level of agreement you mean.

 I can count 6 persons in favor of this. 

>    Diameter messages from the Diameter EAP application.

 maybe the sentence is a little bit strong. We need to carry the EAP
 packets between the HA and the AAAH.

> up with permutation problem in a future.  

 what do you mean ? 

 Julien

> I don't agree with this

-- 
julien.bournelle at int-evry.fr

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 07 Sep 2006 10:15:42 -0400

>  packets between the HA and the AAAH.

Why does a new application with a new application id need to carry EAP
packets?  Why can't it be defined as a totally separate application
that is executed after running EAP application?

> > up with permutation problem in a future.  

Please see the following email:
http://www1.ietf.org/mail-archive/web/dime/current/msg00706.html

Yoshihiro Ohba

---

From: Julien Bournelle <[email-masked]>
Date: Thu, 7 Sep 2006 17:11:03 +0200

Hi yoshi,

> that is executed after running EAP application?

 because EAP application has been defined for network access
 service whereas EAP is basically only for Authentication.

"
 This document specifies the Diameter EAP application that carries EAP
 packets between a Network Access Server (NAS) working as an EAP
 Authenticator and a back-end authentication server.  The Diameter
 EAP application is based on the Diameter Network Access Server
 Application [NASREQ] and is intended for environments similar to
 NASREQ.
"

 So in the EAP Application, EAP is used for the Authentication and the
 AAA server receiving a message with App-ID set to 5 (Diameter-EAP) 
 "knows" implicitely that it is doing this for authorizing 
 network access. NAS-Port-Type or Service-Type helps him to know if it's 
 WiMAX for example. At least, this is my understanding. 

 In our case, as it has already been said, we need to do AAA for the
 Mobile IPv6 service. The "problem" is that the first "A" of AAA is done
 with EAP so we have a sort of overlapping with Diameter EAP. If the
 authentication was done in a totally different way, I guess we won't
 have this problem of App-Id or not.

> http://www1.ietf.org/mail-archive/web/dime/current/msg00706.html

 ok. Let me respond to this in your mail.

 Thanks,

 Julien

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 07 Sep 2006 15:57:19 -0400

Hi Julien,

I was not saying that first A (authentication) should be done in
different way.  What I am saying that second A (authorization) can be
defined separately from the first A and can be run sequencially (i.e.,
an application for second A (e.g., MIP6 bootstrapping) follows another
application for first A (e.g., EAP).

Yoshihiro Ohba

---

From: Julien Bournelle <[email-masked]>
Date: Fri, 8 Sep 2006 15:04:30 +0200

Hi yoshi,

On Thu, Sep 07, 2006 at 03:57:19PM -0400, Yoshihiro Ohba wrote:
> different way.  

 I didn't assume that. My formulation was probably unclear.

> What I am saying that second A (authorization) can be

 ok. I understood this. Let me rephrase the question I asked you in the
 mail http://www1.ietf.org/mail-archive/web/dime/current/msg00718.html.

 So what you proposed is to consider that Diameter-EAP is used only for
 Authentication and to define specific messages to Authorize Mobile
 IPv6. If i'm correct this brings 3 questions in my mind:

 1/ do these messages will have a new Application-Id for mip6 ?

 2/ how does the AAA server know that it is using Diameter EAP only for
 Authentication and not to do full AAA for network access ?

 3/ if we do what you proposed,  we would have specific messages 
 authorizing mip6 service, but then wouldn't it require specific
 messages authorizing network access ?

 regards,

 Julien

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 08 Sep 2006 09:46:02 -0400

Hi Julien,

>  1/ do these messages will have a new Application-Id for mip6 ?

Yes.

>  Authentication and not to do full AAA for network access ?

The AAA server for Diameter EAP is always doing network access
authentication/authorization.  In the case of split scenario, the AAA
server for Diameter EAP would be authorizing the use of IPsec between
MN and HA, but the NAS should not respond to MN at this point because
from MIPv6 perspective this is not a full authorization.  In the case
of integrated scenario, the AAA server for Diameter EAP is authorizing
the use of the link in the visited network.  In both cases, additional
MIPv6 specific information will be obtained from the other Diameter
application specific to MIPv6.

>  messages authorizing network access ?

I may not fully understand this question, but if you are asking
whether Diameter EAP application needs to be modified to support MIPv6
bootstrapping, my answer is no.

Yoshihiro Ohba