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

From: <[email-masked]>
Date: Tue, 5 Sep 2006 07:58:34 +0200

Hi HAnnes, 

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: 1. syyskuuta 2006 1:07
> To: [email-masked]
> Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type 
> 
> 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) for now.. or as long as the NAS-2-AAAH main function
is to provide access authentication, where the backend AAA may return
MIP6
bootstrapping info (as an enhancement) based e.g. on the user
subscription
profile. If we go for more stuff on NAS-2-AAAH like HoA/prefix etc then
(1)
might be better.

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

I would prefer (1) here. The use of EAP for MIP6 bootstrapping purposes
and for 'normal' EAP-based access authentication are different
applications
imho. (although in IKEv2 vs 802.1X case e.g. NAS-Port-Type could be used
to
make this distinction.. e.g. how 3GPP WLAN stuff does it)

> It might be useful to state a reason for your decision.
> 
> Please also indicate whether some aspects are still unclear to you.
> 
> Ciao
> Hannes

Cheers,
	Jouni

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

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

---

From: "Gerardo Giaretta" <[email-masked]>
Date: Tue, 5 Sep 2006 09:35:10 +0200

Hi Hannes,

I agree with Jouni. I prefer (2) for NAS-AAAH and (1) for AAAH-HA. In
my understanding, there are no mandatory AVPs for NAS-AAAH and
therefore I don't see a need of a new application; it's just a
MIP-specific information that is piggybacked in the network access
authentication procedure.

Concerning AAAH-HA, I think it is a much cleaner approach to define a
new application, since it does not anything to do with network
authentication.

--Gerardo

---

From: "Avi Lior" <[email-masked]>
Date: Tue, 5 Sep 2006 07:07:13 -0400

I must be missing something.

In the integrated scenario, what would the NAS put in Service-Type?

I think in the integrated scenario neither Port-Type or Service-Type
needs to be touched.

As far as I understand the NAS is either executing EAP Application or
NAS REQ.  It does not know whether the user will result in having
subsequent Mobile IP service or not.

The only thing the AAA server can do is to send the MIPv6 attributes as
optional (M bit off) and hope that if the NAS does not understand the
attributes it would have some logic to bootstrap a different way.

We could improve the situration somewhat.  We could have the NAS
indicate that it supports MIPv6 bootstrapping by including hints in the
AR (a capability hint).   Where the NAS includes HA-IP address AVP both
indicating that it can support bootstrapping and if the HA-IP address is
not ALL-ZEROS or ALL ONES it provides a hint that it can support dynamic
HA assignement.

Ofcourse we could introduce the concept of capability hints more
formally in Diameter -- This is missing today.

> From: Gerardo Giaretta [mailto:[email-masked]] 
> Sent: Tuesday, September 05, 2006 3:35 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. 
> Service-Type
> 
> Hi Hannes,
> 
> I agree with Jouni. I prefer (2) for NAS-AAAH and (1) for 
> AAAH-HA. In my understanding, there are no mandatory AVPs for 
> NAS-AAAH and therefore I don't see a need of a new 
> application; it's just a MIP-specific information that is 
> piggybacked in the network access authentication procedure.
> 
> Concerning AAAH-HA, I think it is a much cleaner approach to 
> define a new application, since it does not anything to do 
> with network authentication.
> 
> --Gerardo
> 
> > > scenario; as one part of the solution component)
> >
> > I would prefer (2) for now.. or as long as the NAS-2-AAAH main 
> > function is to provide access authentication, where the backend AAA 
> > may return
> > MIP6
> > subscription profile. If we go for more stuff on NAS-2-AAAH like 
> > HoA/prefix etc then
> > (1)
> > might be better.
> >
> > I would prefer (1) here. The use of EAP for MIP6 bootstrapping 
> > purposes and for 'normal' EAP-based access authentication are 
> > different applications imho. (although in IKEv2 vs 802.1X case e.g. 
> > NAS-Port-Type could be used to make this distinction.. e.g. 
> how 3GPP 
> > WLAN stuff does it)
> >