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

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Tue, 5 Sep 2006 14:00:52 -0400

Gerardo,

Are there any mandatory AVP between HA-HAAA for IKEv2 auth for MIP6?

-Kuntal

> -----Original Message-----
> From: Gerardo Giaretta [mailto:[email-masked]]
> Sent: Tuesday, September 05, 2006 2: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

"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: <[email-masked]>
Date: Fri, 8 Sep 2006 08:21:51 +0200

> From: Julien Bournelle [mailto:[email-masked]] 
> Sent: 7. syyskuuta 2006 12:15
> To: Avi Lior
> Cc: [email-masked]
> On Wed, Sep 06, 2006 at 12:53:57PM -0400, Avi Lior wrote:
> > We if we use NASPortType we would have to make it mandatory (it is
> > optional to use but must understand) but we will add a new 
> value, then
> > we would need a new Application ID.  Same for Service-Type. 
>  Only a new
> > NASREQ or EAP AAA server will understand the new value for these
> > attributes.  So inorder to make sure you land at the 
> correct server you
> > need an Application ID.
> > 
> > So yes we could create a new Application ID.
> > 
> > This is not a very good situation.
> > 
> > For integrated scenario I think we need to introduce an optional
> > attribute which is both optional to use and optional to understand.
> > Hence we don't need a new Application ID.
> > 
> > If a NAS does support bootstrapping for MIPv6 it includes 
> the attribute
> > in AR (NASREQ or EAP).
> > 
> > If it lands at a Server that understands this attribute, 
> then it will
> > respond correctly if it wants to bootstrap MIPv6.  If it lands at a
> > Server that doesn't understand the attribute then 
> bootstrapping via AAA
> > will not occur.  Note that if the NAI routes to a AAA 
> server in the home
> > network that doesn't recognize the hint then most likely 
> the operator
> > doesn't want to use bootstrapping or the integrated scenario.

Right.. agree.

/Jouni

> 
>  I agree with this approach for the "NAS-AAAH" part of the mip6
>  bootstrapping.
> 
>  Julien
> 
> > 
> > 
> > 
> > 
> > 
> > > From: Chowdhury, Kuntal [mailto:[email-masked]] 
> > > Sent: Wednesday, September 06, 2006 10:55 AM
> > > To: Avi Lior; Gerardo Giaretta; [email-masked]
> > > Cc: [email-masked]
> > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. 
> > > Service-Type
> > > 
> > > Avi,
> > > 
> > > > IMO the only thing we can do is to hint at the capability 
> > > of the NAS.
> > > 
> > > If we decide to convey NAS capability via an AVP, we may have 
> > > to make the AVP mandatory, right? If so, can we avoid a 
> new APP-ID?
> > > 
> > > -Kuntal
> > > 
> > > 
> > > > From: Avi Lior [mailto:[email-masked]]
> > > > Sent: Tuesday, September 05, 2006 10:21 PM
> > > > To: Chowdhury, Kuntal; Gerardo Giaretta; 
> [email-masked]
> > > > Cc: [email-masked]
> > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs.
> > > Service-Type
> > > > 
> > > > Hi Kuntal,
> > > > 
> > > > Neither option 1 or option 2 will work.  A new 
> application id just
> > > wont
> > > > scale in the long run.  What if another 'capability' were 
> > > to be added 
> > > > for instance prepaid.  Since Diameter messages contain only one 
> > > > Application ID,  you would have to create an Application Id that
> > > covered
> > > > both EAP, Prepaid and Mobile IP. And what if a third 
> > > application were 
> > > > added?  The approach is not scalable as the applications 
> > > are increased
> > > > -- you would have to cope with all the different 
> permutations of 
> > > > Applications.  The same argument goes for ServiceType and 
> > > PortType and 
> > > > these are actually more problematic.
> > > > 
> > > > IMO the only thing we can do is to hint at the capability 
> > > of the NAS.
> > > > 
> > > > A proper solution should be concieved for this problem.
> > > > 
> > > > 
> > > > > From: Chowdhury, Kuntal 
> [mailto:[email-masked]]
> > > > > Sent: Tuesday, September 05, 2006 2:09 PM
> > > > > To: Avi Lior; Gerardo Giaretta; [email-masked]
> > > > > Cc: [email-masked]
> > > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs.
> > > > > Service-Type
> > > > >
> > > > > All,
> > > > >
> > > > > Here is a scenario that may need to be covered. In some 
> > > cases, local 
> > > > > HA assignment is optimal for transport efficiency 
> perspective. 
> > > > > Diameter
> > > > > MIP4 application allows this. In such a case the ASP == 
> > > MSP and the 
> > > > > HA is assigned locally (in the visited network).
> > > > >
> > > > > To enable this case, in the integrated scenario, the 
> > > NAS/VAAA needs 
> > > > > to indicate it's capability to assign an HA in the local 
> > > network to 
> > > > > the HAAA. The HAAA may allow or disallow this local 
> HA assignment 
> > > > > based on policy of the MSA.
> > > > >
> > > > > The NAS/VAAA may need to include a hint in the AAA 
> message to the 
> > > > > HAAA at the time of access authentication that it is 
> capable of 
> > > > > providing an HA to the MN. This capability indication 
> > > (hint) can be 
> > > > > either sent via a new MIP6 specific AVP or it can be 
> > > conveyed via an 
> > > > > existing AVP (I don't know if one exists).
> > > > >
> > > > > If we decide to include this (local HA assignment), and 
> > > we decide to 
> > > > > include this mip6 specific hint in the NAS-HAAA 
> communication, we 
> > > > > may have to choose the most appropriate option (1) vs. (2).
> > > > >
> > > > > Comments?
> > > > >
> > > > > -Kuntal
> > > > >
> > > > >
> > > > > > From: Avi Lior [mailto:[email-masked]]
> > > > > > Sent: Tuesday, September 05, 2006 6:07 AM
> > > > > > To: Gerardo Giaretta; [email-masked]
> > > > > > Cc: [email-masked]
> > > > > > Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs.
> > > > > Service-Type
> > > > > >
> > > > > > 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.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > > Sent: Tuesday, September 05, 2006 3:35 AM
> > > > > > > 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
> > > > > > > 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
> > > > > > >
> > > > > > > > > It is time to see what the group thinks. 
> Please indicate
> > > > > > > whether you
> > > > > > > > > scenario; as one part of the solution component)
> > > > > > > >
> > > > > > > > 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.
> > > > > > > >
> > > > > > > > > (b) HA-to-AAAH communication (as used by the split
> > > > > > > scenario and the
> > > > > > > > > integrated scenario)
> > > > > > > >
> > > > > > > > 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)
> > > > > > > >
> > > > > > > > > Please also indicate whether some aspects are still
> > > > > > > unclear to you.
> > > > > > > > >
> > > > > > > > > Ciao
> > > > > > > > > Hannes
> > > > > > > >
> > > > > > > > Cheers,
> > > > > > > >         Jouni
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > "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."
> > > > >
> > > 
> > 
> -- 
> julien.bournelle at int-evry.fr
>