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

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Thu, 7 Sep 2006 10:31:20 -0400

All,

For NAS-HAAA transaction, all we need the NAS to do is to send a hint to
the HAAA that it can handle mip6 bootstrap attribute(s) if the HAAA
decides to send those in the Diameter EAP/NASREQ response, that's all.

Now, let's see the options we have to convey this hint:

1. APP-id: may be an overkill for a hint, but may be the cleanest
solution.

2. NAS-port-type: the new value may need to be overloaded to convey more
than one hint.

3. Capability AVP: the NAS that support mip6bootstrapping can include
this optional AVP in the Diameter EAP/NASREQ messages.

Option 3, seems to be simple enough to serve the purpose i.e. convey the
hint, IMHO. Let me know if you think otherwise.

-Kuntal

> -----Original Message-----
> From: Avi Lior [mailto:[email-masked]] 
> Sent: Thursday, September 07, 2006 4:32 AM
> To: Julien Bournelle; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. 
> Service-Type
> 
> 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.
> 
> > -----Original Message-----
> > 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]
> > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. 
> > Service-Type
> > 
> > Hi,
> > 
> > On Tue, Sep 05, 2006 at 01:38:45PM +0200, 
> > [email-masked] wrote:
> > > 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.
> > 
> >  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
> > 
> > > 
> > > > 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
> > 
> > --
> > julien.bournelle at int-evry.fr
> > 
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dime
> 

"This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to [email-masked] -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you."

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 12 Sep 2006 11:16:34 -0400

Hi Kuntal,

In option 3, what does "optinal AVP" means?  Does it mean that 'M' bit
of the AVP is unset, or 'M' bit of the AVP is set but the AVP is
defined to appear in optional part in ABNF?

Yoshihiro Ohba