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

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 21 Sep 2006 03:07:15 -0400

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

---

From: Tina TSOU <[email-masked]>
Date: Wed, 27 Sep 2006 14:59:00 +0800

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.

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

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

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.

B. R.
Tina 
Messengers: 
MSN: [email-masked]   Yahoo: tina_tsou    Skype: tinaTSOU    Jabber: [email-masked]

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 27 Sep 2006 10:09:30 +0200

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.

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

---

From: Tina TSOU <[email-masked]>
Date: Fri, 29 Sep 2006 09:48:49 +0800

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

> a little bit more details particularly with regard to the scenario you 
In my mind, the scenarios are PCC (piggyback charging and QoS), and Rs/Gq/Gq' (piggyback authorization and QoS).