Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type

From: Julien Bournelle <[email-masked]>
Date: Fri, 1 Sep 2006 11:40:04 +0200

Hi hannes, all,

On Fri, Sep 01, 2006 at 12:07:23AM +0200, Hannes Tschofenig wrote:
> Hi all,
> 
> we have had long discussions about the App-ID vs. Service-Type usage for 
> Diameter MIPv6 Bootstrapping.
> 
> It is time to see what the group thinks. Please indicate whether you 
> prefer (1) an App-ID or (2) a Service-Type solution for
> 
> (a) NAS-to-AAAH communication (as required by the integrated scenario; 
> as one part of the solution component)

 I would prefer (2) or a NAS-Port-Type AVP.

 The reason is that here we're doing AAA for network access. And as part
 of this process we deliver the HA to the NAS. Then the MN gets this
 info by using DHCP (cf. draft-ietf-mip6-integrated-dhc).
 Adding an AVP to the AAA exchanges (Diameter NASREQ/EAP) helps the AAA
 server to know if the NAS supports what is described in the mentionned
 draft (mip6-integrated).

> (b) HA-to-AAAH communication (as used by the split scenario and the 
> integrated scenario)

 I would prefer (1) 
 
 The reason is that the AAA server must know that it is doing AAA for
 the Mobile IPv6 service and not for network access. And to have this,
 from what we've discussed in the list (and from what I've understood), 
 we need an App-ID.

 regards,

 Julien Bournelle

> 
> It might be useful to state a reason for your decision.
> 
> Please also indicate whether some aspects are still unclear to you.
> 
> Ciao
> Hannes
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dime

-- 
julien.bournelle at int-evry.fr

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

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 01 Sep 2006 17:27:15 -0700

Hi Hannes,

For b) I prefer an App ID (1) as it is not clear whether the MIP6 within
Diameter will be similar to that of MIP4 (messaging, functionality and all),
in fact they may be quite different.

For a) I still prefer a new App ID (1) for the same reason as above.
Although in this case you may still need a new NAS-type (=HA) if HA is also
a NAS.

Madjid 
-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Thursday, August 31, 2006 3:07 PM
To: [email-masked]
Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type

Hi all,

Ciao
Hannes

---

From: Julien Bournelle <[email-masked]>
Date: Sat, 2 Sep 2006 16:19:31 +0200

Hi madjid,

 Just some clarifications:

> in fact they may be quite different.

 As I already explained in a previous mail, mip6 case and mip4 case are
 totally different. To sum up a little, in mip4, the MN sends a Reg-Req
 with a MN-AAA-Auth field to the HA. The HA then uses RFC4004 with the AAA
 server. The message sent by the HA carry the MN-AAA-Auth for the
 authentication. RFC4004 is a little more complicated since the Reg-Req
 could be sent to the FA and some keys may be distributed.

 In the mip6 case, the MN uses IKEv2 with the HA to setup necessary
 IPsec SAs and EAP is used by the HA to authenticate the MN. The HA
 relies on a AAA/EAP server. Thus we'll have DER/DEA messages but in the
 same time, the AAA/EAP server need to know that it is for mip6 service
 and not for network access.
> Although in this case you may still need a new NAS-type (=HA) if HA is also

 for a/ the NAS is a NAS for network access. It can't be a HA. The MN
 (or not MN) contacts the NAS to be authenticated for network access.
 The NAS even doesn't know if it's a MN or not. I don't understand how
 it can be similar to (b). Based on the user'profile, the AAA may decide
 to provide him HA info through AAA messages (AAA if NASREQ is used, DEA
 if it's DIameter EAP). Then the MN gets the HA info with DHCP. And
 finally it contacts the HA as it is described in the split document.

 Hope it helps,

 Julien

---

From: "Ram O V Vishnu-A14676" <[email-masked]>
Date: Mon, 4 Sep 2006 22:35:12 +0800

Hannes,

I prefer 

- (1) for (a): because the peers (agents for example) could decide based
on the advertisement of the app that its capable of, lets say, the
integrated scenario.

- (1) for (b): But I don't understand how a node in the middle (like the
HA) can decide the purpose of the EAP authentication (for mip6 service
or network access), EAP being an e-2-e protocol. It runs between the MN
(EAP peer) and the Backend Server (AAA). So if the AAA is confused about
what its trying to authenticate for, then shouldn't the MN be too?

Regards,
Vishnu.

Motorola
+91 9844178052
[*] General
[] Motorola Internal Use Only

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Friday, September 01, 2006 3:37 AM
To: [email-masked]
Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type 

Hi all,

Ciao
Hannes

---

From: "Avi Lior" <[email-masked]>
Date: Mon, 4 Sep 2006 12:37:21 -0400

I need to resynch on the scenarios.

However, if we decide to modify ServiceType or NAS Port type we should
modify NAS Port Type to add a MIPv6 port type etc.
We should not touch ServiceType (this will help us in RADIUS as well).

> Sent: Thursday, August 31, 2006 6:07 PM
> To: [email-masked]
> we have had long discussions about the App-ID vs. 
> Service-Type usage for Diameter MIPv6 Bootstrapping.
> 
> It is time to see what the group thinks. Please indicate 
> whether you prefer (1) an App-ID or (2) a Service-Type solution for
> 
> (a) NAS-to-AAAH communication (as required by the integrated 
> scenario; as one part of the solution component)
> 
> (b) HA-to-AAAH communication (as used by the split scenario 
> and the integrated scenario)
>

---

From: "Avi Lior" <[email-masked]>
Date: Mon, 4 Sep 2006 12:42:02 -0400

Hi Julien,

> From: Julien Bournelle [mailto:[email-masked]] 
> Sent: Friday, September 01, 2006 5:40 AM
> To: Hannes Tschofenig
> Cc: [email-masked]
> Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. 
> Service-Type
> 
> Hi hannes, all,
> 
> whether you 
>  The reason is that here we're doing AAA for network access. 
> And as part  of this process we deliver the HA to the NAS. 
> Then the MN gets this  info by using DHCP (cf. 
> draft-ietf-mip6-integrated-dhc).
>  Adding an AVP to the AAA exchanges (Diameter NASREQ/EAP) 
> helps the AAA  server to know if the NAS supports what is 
> described in the mentionned  draft (mip6-integrated).

I prefer NAS-Port-Type but what would you set the value of the
NAS-Port-Type to?
And similarly the if you were to use Service-Type, what value would you
set it to to provide a hint.

How does the AAA know that the NAS can support the attribute it will
send to it.  If it doesn't support the attributes the NAS will just
throw the attributes away no?

>  The reason is that the AAA server must know that it is doing 
> AAA for  the Mobile IPv6 service and not for network access. 
> And to have this,  from what we've discussed in the list (and 
> from what I've understood),  we need an App-ID.

I agree.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 08 Sep 2006 10:10:21 -0400

I forgot to explicitly answer to this question.

My answer is (1) for both (a) and (b), but define MIP6 application as
a totally separate authprization application from EAP and NASREQ (For
more details and reasons, please see related discussion with Julien).

Regards,
Yoshihiro Ohba

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 21 Sep 2006 03:06:46 -0400

Hi Yoshi,

the drawback is that this approach is less efficient.
If we see this in relationship with RADIUS I already see people saying
that the Diameter approach is a performance hit.

Still, I think it is worth investigating in the current document.

Ciao
Hannes

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 22 Sep 2006 09:45:49 -0400

> that the Diameter approach is a performance hit.

But can't EAP application and MIP6 application be executed in
parallel?  I believe parallel run is possible once after NAS or HA
obtains user's identity or equivalent from EAP application.

Yoshihiro Ohba