Subject: RE: [Dime] My Summary of the MIPv6 Bootstrapping Discussion

From: <[email-masked]>
Date: Tue, 3 Oct 2006 13:49:26 +0200

Hi Yoshihiro, 

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:[email-masked]] 
> Sent: 3. lokakuuta 2006 4:05
> To: Hannes Tschofenig
> Cc: [email-masked]
> Subject: Re: [Dime] My Summary of the MIPv6 Bootstrapping Discussion
> 
> Hi Hannes,
> 
> On Thu, Sep 21, 2006 at 03:07:15AM -0400, Hannes Tschofenig wrote:
> > Hi all,
> > 
> > let me try to summarize what was discussed recently with regard to 
> > MIPv6 bootstrapping.
> > 
> > We agreed that it would be useful to differentiate the 
> following two cases:
> > 
> > (1) NAS<->AAA Server
> > 
> > (2) HA<->AAA Server
> > 
> > [We need to change the titles of our document a bit.]
> > 
> > With regard to (1) a number of folks were in favor of introducing a 
> > capability mechanism that allows the NAS to indicate that 
> it supports 
> > a certain functionality. As Avi said, this newly required 
> AVP would be 
> > optional to use and optional to understand. 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.
> 
> I would like to do more deep analysis on this solution.  It 
> sounds like not only the capability AVP but also all other 
> MIPv6-related AVPs need to be defined as optional to use and 
> optional to understand in order to get around the 

I thought this was the case already. All AVPs for the NAS-AAAH are
supposed
to optinal.

> permutations problem with NASREQ and EAP.  If we consider 
> general applicability of this solution to other applications 
> such as QoS, an application may want to have some 
> application-specific AVPs to be mandatory to use for the 
> application to work while some other application-specific 
> AVPs to be optional to use, but if we need to define all 
> application-specific AVPs to be optional to use and optional 
> to understand, such differentiation among 
> application-specific AVPs would be no longer possible, which 
> might lead to an interoperability issue as far as I can 

Well that's true but I'm not sure if it is an issue with NAS-AAAH as
that is more like an optimization done during the access auth. The MN
has always a way (hopefully ;) to fallback to other bootstrapping method
if the integrated scenario fails.

> anticipate.  It might be possible to expect each application 
> to define more detailed AVP processing rule to overcome this 
> issue, i.e., defining a detailed set of rules to deal with 

That's what other SDOs tend to do for their own deploymeent scenarios.

> the case where AVPs that are define as *optional to use in 
> ABNF but actually mandatory to use in the
> application* are missing, but we are not taking an advantage 
> of ABNF to differentiate required AVPs from optional ones any more.
>
> Regards,
> Yoshihiro Ohba

Cheers,
	Jouni

> 
> > 
> > Defining a new AppID is not needed and consequently the Diameter 
> > NASREQ/EAP message would hit the same server that also 
> supports MIPv6 
> > bootstrapping.
> > 
> > As an alternative, Yoshi suggested to go along the same 
> approach as in 
> > (2). The drawback would be the performance hit. This would, 
> however, 
> > allow the two servers to be different (if this is at all useful).
> > 
> > With regard to (2) Yoshi suggested a new AppID to be used for 
> > Authorization and Accounting and not to reuse the EAP/NASREQ ABNF.
> > As Julien wrote, we are able to continue to use Diameter EAP for 
> > Authentication. Thus, the HA will use Diameter EAP with the AVP 
> > Auth-Request-Type set to AUTHENTICATE_ONLY and then the HA will use 
> > this
> > MIP6 Application for Authorization/Accounting of the Mobile 
> IPv6 service.
> > 
> > This would avoid to update the application if RFC 4072 is 
> updated and 
> > this could be a way to proceed if other applications need EAP for 
> > Authentication but have different needs for the Authorization and 
> > Accounting part.
> > 
> > Again, there is a performance disadvantage if a separate 
> exchange is 
> > used instead of piggybacking functionality.
> > 
> > [I am still not sure how this nicely interworks with the 
> QoS work we 
> > do in the group. That's for further investigation.]
> > 
> > I think we made progress in our discussions. Julien has initiated a 
> > poll to see what todo regarding (2) and whether the group likes 
> > Yoshi's suggestion. For (1) I got the impression that the focus 
> > currently is more on the capability exchange but we might need to 
> > initiate another poll there as well.
> > 
> > Btw, the conclusions we make in this discussion can also be 
> reused for 
> > the Diameter QoS work.
> > 
> > Ciao
> > Hannes
> > 
> > _______________________________________________
> > 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: Yoshihiro Ohba <[email-masked]>
Date: Tue, 3 Oct 2006 18:36:46 -0400

Hi Jouni,

> I thought this was the case already. All AVPs for the NAS-AAAH are

Most AVPs defined in NASREQ and EAP are defined as optional to use but
mandatory to understand (i.e., 'M' bit is set).  The above solution is
different (worse) in that the AVPs are not only optional to use but
also optional to understand.

Yoshihiro Ohba