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

From: <[email-masked]>
Date: Tue, 5 Sep 2006 13:38:45 +0200

Avi, 

> I must be missing something.
> 
> In the integrated scenario, what would the NAS put in Service-Type?

Something MIP6 indicating that is not defined yet.

> 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.

Yes. But there was this discussion/idea earlier that it could be
benefical
from the AAA server point of view to have a hint whether the NAS
supports intergrated scenario at all.

> 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

And why can't the Service-Type or NAS-Port-type serve as a hint? e.g.
NAS-Port-Type has been used in some architectures to distinguish
between .1X or IKEv2 originating EAP requests.

Well.. we could also put a bunch of AVPs to the access requests
that would serve as a capability hint.

> 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.

Cheers,
	Jouni

> 
> 
> 
>  
> 
> > -----Original Message-----
> > 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
> > 
> > On 9/5/06, [email-masked] 
> > <[email-masked]> wrote:
> > > 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
> > >
> > 
> > _______________________________________________
> > DiME mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/dime
> > 
> 
> _______________________________________________
> 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: Julien Bournelle <[email-masked]>
Date: Thu, 7 Sep 2006 11:10:02 +0200

Hi,

> between .1X or IKEv2 originating EAP requests.

 I'm thinking that the NAS will certainly add a NAS-Port-Type even if it
 supports mip6 integrated case. So this would mean that it will add 2
 NAS-Port-Type ?
> that would serve as a capability hint.

 yes. I tend to think that a sort of capability AVP here is interesting
 and may solve what we want.

 Julien

-- 
julien.bournelle at int-evry.fr

---

From: "Avi Lior" <[email-masked]>
Date: Thu, 7 Sep 2006 05:31:48 -0400

At the NAS the NAS should not report NAS-Port-Type = MIP because it does
not support MIP necessarily, it is just bootstrapping some DHCP
parameters.

Maybe NAS-Port-Type = MIPv6DHCPBoot? Yuk.

Here is the Defn of NAS Port type:

The NAS-Port-Type AVP (AVP Code 61) is of type Enumerated and
   contains the type of the port on which the NAS is authenticating the
   user.  This AVP SHOULD be present if the NAS uses the same NAS-Port
   number ranges for different service types concurrently.

Forgetting the last sentence.  The NAS is not authenticating the user
for MIP necessarily.  It really doesn't know in all cases what the user
will get in the integrated case.

IMO a fair usage for NAS-Port-Type is for example in WiMAX, setting
NAS-Port-Type = WiMAX.  Now the home aaa will know that the NAS is
authenticating a WiMAX type Port -- which could be MIPv4, PMIPv4, MIPv6
etc....

In the case of WiMAX for example, the HAAA will know that a WiMAX NAS
can support bootstrapping -- because it may be a requirement on the NAS
to do so. So that is sufficient.  But in general we may need something
better then that.

Secondly the last time I looked you MAY only have one instance of
NAS-Port-Type.

I think using NAS-Port-Type as a hint in this case is not possible and
IMO not recommended.

> From: Julien Bournelle [mailto:[email-masked]] 
> Sent: Thursday, September 07, 2006 5:10 AM
> To: [email-masked]
> Cc: Avi Lior; [email-masked]; 
> [email-masked]; [email-masked]
> > > 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 
> > benefical from the AAA server point of view to have a hint 
> whether the 
> > NAS supports intergrated scenario at all.
> > 
> 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.
> > > 
> > > indicate that it supports MIPv6 bootstrapping by 
> including hints in 
> > > the
>  I'm thinking that the NAS will certainly add a NAS-Port-Type 
> even if it  supports mip6 integrated case. So this would mean 
> that it will add 2  NAS-Port-Type ?
> > 
> > Well.. we could also put a bunch of AVPs to the access 
> requests that 
> > would serve as a capability hint.
> 
>  yes. I tend to think that a sort of capability AVP here is 
> interesting  and may solve what we want.
> 
>  Julien
> 
> > 
> > > address is not ALL-ZEROS or ALL ONES it provides a hint 
> that it can 
> > > support dynamic HA assignement.
> > > 
> > > > 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.
> > > > 
> > > > define a new application, since it does not anything to do with 
> > > > network authentication.
> > > > 
> > > > --Gerardo
> > > >