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

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Fri, 29 Sep 2006 00:40:04 -0400

Tina,

> In my mind, the scenarios are PCC (piggyback charging and QoS), and
> Rs/Gq/Gq' (piggyback authorization and QoS).

AFAIK, PCC interactions (3GPP:Gx/ 3GPP2:Ty) are kept separate from
auth/authz steps for network entry.

-Kuntal

> -----Original Message-----
> From: Tina TSOU [mailto:[email-masked]]
> Sent: Thursday, September 28, 2006 8:49 PM
> To: Hannes Tschofenig
> Cc: [email-masked]
> Subject: Re: [Dime] My Summary of the MIPv6 Bootstrapping Discussion
> 
> Hi Hannes,
> See in line(:
> 
> B. R.
> Tina
> ----- Original Message -----
> From: "Hannes Tschofenig" <[email-masked]>
> To: "Tina TSOU" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, September 27, 2006 4:09 PM
> Subject: Re: [Dime] My Summary of the MIPv6 Bootstrapping Discussion
> 
> 
> > Hi Tina,
> >
> > thanks for your response.
> >
> > Tina TSOU schrieb:
> > > Hi all, Regarding Diameter MIPv6 work, in my understanding, (1) If
we
> > > consider NAS and HA authenticate/ authorize to different AAA
Servers,
> > > I suggest to define a new Application ID for NAS<-->AAA Server,
and
> > > define another new Application ID for HA<-->AAA Server.
> >
> > So far everyone was questioning the need to use different servers.
> >
> >
> > >
> > > (2)If we consider NAS and HA authenticate/ authorize to a same AAA
> > > Server, I suggest to only define MIPv6 related AVPs in MIPv6 Appl.
> > > Document. For case 1 NAS<-->AAA Server, I suggest to use EAP Appl.
> > > (RFC4072), carry added MIPv6 related AVPs. RFC4072 itself supports
> > > AVP extension, so it could be considered as not modifying RFC4072.
> >
> > Folks raised two issues:
> >
> > * Are these attributes mandatory? So far we said "no".
> > * Do we need something like a capability exchange? I saw a few
"yes".
> >
> > > For case 1 HA<-->AAA Server, I suggest to use NAS Appl. (RFC4005),
> > > carry added MIPv6 related AVPs. RFC4005 itself supports AVP
> > > extension, so it could be considered as not modifying RFC4005.
> >
> > If you only add a non-mandatory AVP then you don't need to touch
NASREQ
> > or EAP at all.
> >
> > >
> > > (1) can bring more flexibility, however we have risk not stop
> > > extending Application ID. If in the real world, the AAA servers
for
> > > NAS and HA are the same one, (2) is better.
> >
> > That's also the conclusion folks came to on the mailing list (from
what
> > I can tell).
> >
> > >
> > > Regarding Diameter QoS work, in my understanding, QoS appl. is
needed
> > > for every call/session procedure, MIPv6 appl. is only needed for
the
> > > UE registration procedure.  If we don't combine QoS appl., it
might
> > > cause signaling delay; hence the response to user call behaves
> > > slowly. So QoS appl. is strongly suggested to be piggybacking with
> > > other procedure. And even if MIPv6 is not piggybacking with other
> > > procedure, from the user perspective, it represents a bit slower
> > > registration, users could live with it.
> >
> > I am not so sure I understand what you mean. I guess you need to
provide
> > a little bit more details particularly with regard to the scenario
you
> > have in mind.
> In my mind, the scenarios are PCC (piggyback charging and QoS), and
> Rs/Gq/Gq' (piggyback authorization and QoS).
> >
> > Ciao
> > Hannes
> >
> > > B. R. Tina Messengers: MSN: [email-masked]   Yahoo:
tina_tsou
> > > Skype: tinaTSOU    Jabber: [email-masked]
> > >
> > > ----- Original Message ----- From: "Hannes Tschofenig"
> > > <[email-masked]> To: <[email-masked]> Sent: Thursday,
> > > September 21, 2006 3:07 PM Subject: [Dime] My Summary of the MIPv6
> > > Bootstrapping Discussion
> > >
> > >
> > >> 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.
> > >>
> > >> 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

"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: Tina TSOU <[email-masked]>
Date: Fri, 29 Sep 2006 14:31:35 +0800

Kuntal,
Yes, you are right. However, I was misunderstood.
I meant two scenarios (i.e. they are two examples).
Scenario a: PCC (piggyback charging and QoS)
Scenario b: Rs/Gq/Gq' (piggyback authorization and QoS)
 
I'm going to start drafting, could Hannes parse the drafting work a bit specifically?
1) Add more binding mechanisms
2) Editorial change
3) Harmonization of AVPs with other QoS-related profiles
 
B. R.
Tina

----- Original Message ----- 
From: "Chowdhury, Kuntal" <[email-masked]>
To: "Tina TSOU" <[email-masked]>; "Hannes Tschofenig" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, September 29, 2006 12:40 PM
Subject: RE: [Dime] My Summary of the MIPv6 Bootstrapping Discussion

Tina,

-Kuntal

we
Servers,
and
"yes".
NASREQ
for
what
needed
the
might
provide
you
tina_tsou
to
a
required
bootstrap
as
ABNF.
use
a
reused