Subject: [Mip6] Diameter Mobile IPv6 Bootstrapping: Authorizing Route Optimization

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 04 Sep 2007 14:12:58 +0200

Hi all, 

during his review of "Diameter Mobile IPv6: HA<->AAA" Ahmad made the following comment: 

We discussed before that AUTHORIZATION for ROUTE OPTIMIZATION is needed.
I did not see it included here?! As we discussed last time, operators do
care about having control over the willingness of the MN to have route
optimization. If that the case, then there should be a process to enable
that kind of authorization. No?
<<<

Does the group think that we need to provide any backend infrastructure support to enable this type of functionality? 

Ciao
Hannes

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 04 Sep 2007 14:39:18 +0200

Hannes Tschofenig wrote:
> Hi all, during his review of "Diameter Mobile IPv6: HA<->AAA" Ahmad
> made the following comment:
>>>> 
> We discussed before that AUTHORIZATION for ROUTE OPTIMIZATION is
> needed. I did not see it included here?! As we discussed last time,
> operators do care about having control over the willingness of the MN
> to have route optimization. If that the case, then there should be a
> process to enable that kind of authorization. No? <<<
> 
> Does the group think that we need to provide any backend
> infrastructure support to enable this type of functionality?

Which group(s)?

I think RO is designed to work across the entire Internet, not limited
to a AAA-controlled domain.

 From tests, the benefits of running RO on the MN are apparent only when
the distance MN-CN is much shorter than both MN-HA and CN-HA, in terms
of IP hops.

In a closed system, that equation is not valid, ie, MN is close to both
CN and to its HA, and the benefits of running RO are minimal, one
doesn't gain much at all.

So, in first place I don't see why would a MN want to run RO at all
while in a AAA-controlled (closed) domain.  It may very well be that MN
is not interested at all to run RO to a CN outside the AAA-controlled
domain, because it wouldn't gain much.  Then, even if MN would want to
do that, I don't see why asking the local AAA to be authorized to
perform RO.

Finally, are you talking about AAA backend authorizing the MN or the CN
to do RO?

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: <[email-masked]>
Date: Tue, 4 Sep 2007 14:41:06 +0200

> infrastructure support to enable this type of functionality? 

Yes. That could e.g. be part of the subscriber profile.

Cheers,
	Jouni

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 04 Sep 2007 15:54:18 +0200

Hi Alex,

>> infrastructure support to enable this type of functionality?
I should have said "groups", DIME and MIP6.

I should have clarified a bit more what the background of my mail was 
(at least how I understood it).

The home operator is obviously able to prevent route optimization from 
happening. Whether this would be done is most likely attached to a 
subscriber database and could be dynamically downloaded to the Home 
Agent as part of the bootstrapping procedure.

Ciao
Hannes

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 4 Sep 2007 08:57:36 -0500

Hi Alex,

Just some background:

The proposed Diameter MIPv6 Application is used to enable MIPv6 service
authorization + dynamic security association allocation. As per the
current application, the user is authorized for MIPv6 service without a
clear indication if the user is allowed to use Route Optimization or
not. Allowing the operator this flexibility makes a lot of sense. Let us
remember in order for the MN to establish a RO, it needs to have at
least HoTI and HoT signals transmitted via the HA which can act as the
authorization enforcement point.

Of course, we are talking about a network which is controlled by AAA
infrastructure since the proposed application is for Diameter MIPv6. 

Also, please see comments inline.

Regards,
Ahmad

> Subject: Re: [Mip6] Diameter Mobile IPv6 Bootstrapping: 
> Authorizing Route Optimization
> 
> Hannes Tschofenig wrote:
> I think RO is designed to work across the entire Internet, 
> not limited to a AAA-controlled domain.
> 
>  From tests, the benefits of running RO on the MN are 
> apparent only when the distance MN-CN is much shorter than 
> both MN-HA and CN-HA, in terms of IP hops.
> 
> In a closed system, that equation is not valid, ie, MN is 
> close to both CN and to its HA, and the benefits of running 
> RO are minimal, one doesn't gain much at all.
> 
> So, in first place I don't see why would a MN want to run RO 
> at all while in a AAA-controlled (closed) domain.  It may 
> very well be that MN is not interested at all to run RO to a 
> CN outside the AAA-controlled domain, because it wouldn't 
> gain much.  Then, even if MN would want to do that, I don't 
> see why asking the local AAA to be authorized to perform RO.

[Ahmad]
Are you assuming that the HA is always in the visited network? Also,
V-AAA does not communicate with H-AAA?
I just want to understand what you meant here.
Thanks.

> 
> Finally, are you talking about AAA backend authorizing the MN 
> or the CN to do RO?

[Ahmad]
AAA infrastructure only can control the MN to have RO or not and hence
authorization is for the MN not the CN.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 04 Sep 2007 16:20:15 +0200

Ahmad Muhanna wrote:
> Hi Alex,
> 
> Just some background:
> 
> The proposed Diameter MIPv6 Application is used to enable MIPv6 
> service authorization + dynamic security association allocation. As 
> per the current application, the user is authorized for MIPv6 service
>  without a clear indication if the user is allowed to use Route 
> Optimization or not. Allowing the operator this flexibility makes a 
> lot of sense. Let us remember in order for the MN to establish a RO, 
> it needs to have at least HoTI and HoT signals transmitted via the HA
>  which can act as the authorization enforcement point.
> 

Ahmad, thank you for clarification.

As you describe the operator's need it does make sense to me.

There is something to it, however.

If the MN, CN and HA are all in the same domain, HA and CN share IPsec
keys, and if MN and HA develop keys by AAA means, then there is
practically no reason for MIP6 RO to use return routability tests (the
HoT/I and CoT/I) messages.  I mean HoT/I and CoT/I messages are
superfluous and it is possible to do RO without any security concern (eg
send BU to CN through HA, all IPsec'ed).

That's what I meant by MN not needing to do 3775 RO at all in a
AAA-controlled infrastructure.

>> Hannes Tschofenig wrote:
>>> Hi all, during his review of "Diameter Mobile IPv6: HA<->AAA" 
>>> Ahmad made the following comment: We discussed before that 
>>> AUTHORIZATION for ROUTE OPTIMIZATION is needed. I did not see it 
>>> included here?! As we discussed last time, operators do care 
>>> about having control over the willingness
>> of the MN
>> I think RO is designed to work across the entire Internet, not 
>> limited to a AAA-controlled domain.
>> 
>> From tests, the benefits of running RO on the MN are apparent only 
>> when the distance MN-CN is much shorter than both MN-HA and CN-HA, 
>> in terms of IP hops.
>> 
>> In a closed system, that equation is not valid, ie, MN is close to 
>> both CN and to its HA, and the benefits of running RO are minimal, 
>> one doesn't gain much at all.
>> 
>>  while in a AAA-controlled (closed) domain.  It may very well be 
>> that MN is not interested at all to run RO to a CN outside the 
>> AAA-controlled domain, because it wouldn't gain much.  Then, even 
>> if MN would want to do that, I don't see why asking the local AAA 
>> to be authorized to perform RO.
> 
> [Ahmad] Are you assuming that the HA is always in the visited 
> network?

Right, I did.

> Also, V-AAA does not communicate with H-AAA? I just want to 
> understand what you meant here. Thanks.

Right...

Anyways I don't see AAA to scale anywhere to the size of the Internet.

If AAA is used in one closed system (or two WiMax-like ASN+CSN systems)
then I think there's little need for RO.

Probably, I mean probably because depends on so many other factors, if
MN attaches to ASN and its H-AAA is in the CSN, and MN is outside both
CSN and ASN, but much closer to ASN than to CSN, then MN may gain
something by doing RO to it.

This necessity depends so much on the deployment scenario and placement
of different networks.

>> Finally, are you talking about AAA backend authorizing the MN or 
>> the CN to do RO?
> 
> [Ahmad] AAA infrastructure only can control the MN to have RO or not 
> and hence authorization is for the MN not the CN.

I'd like to identify first whether MN needs to do RO or not, and only
then look at whether it needs to be authorized or not.

For your description, do you think that when MN attaches to a WiMax
network's ASN and talks to an arbitrary CN on the Internet - will the
MN-CN normal traffic go all the way to CSN first?

Alex
ASN: Access Service Network
CSN: Connectivity Service Network

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 4 Sep 2007 11:00:18 -0500

Hi Alex,
Please see comments inline.

Regards,
Ahmad
 
> 
> >> Finally, are you talking about AAA backend authorizing the 
> MN or the 
> >> CN to do RO?
> > 
> I'd like to identify first whether MN needs to do RO or not, 
> and only then look at whether it needs to be authorized or not.
> 
> For your description, do you think that when MN attaches to a 
> WiMax network's ASN and talks to an arbitrary CN on the 
> Internet - will the MN-CN normal traffic go all the way to CSN first?

[Ahmad]
It depends. I assume we are talking about Client MIPv6 here. 
In case the MN uses the HoA as a source IP address, I believe the
traffic will go to the node which defends the HoA address; right?

Now, if the MN can use its CoA as a source IP address, then traffic is
not necessarily sent to the entity which defends the HoA, i.e. arbitrary
CN in your case.

I guess allowing the Home Network the option to force user traffic
through the home network, IMO, makes a good business case and a
flexibility for the operator to use for offering different service
models. 
I believe I am going beyond the technicality of the issue here; I hope I
am correct.:-)

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 04 Sep 2007 18:19:18 +0200

Ahmad Muhanna wrote:
> Hi Alex, Please see comments inline.
> 
> Regards, Ahmad
> 
>> I'd like to identify first whether MN needs to do RO or not, and
>> only then look at whether it needs to be authorized or not.
>> 
>> network's ASN and talks to an arbitrary CN on the Internet - will
>> the MN-CN normal traffic go all the way to CSN first?
> 
> [Ahmad] It depends. I assume we are talking about Client MIPv6 here.

I believe so... I think the entity defending that address is HA in CSN.

> Now, if the MN can use its CoA as a source IP address, then traffic
> is not necessarily sent to the entity which defends the HoA, i.e.
> arbitrary CN in your case.

Right, and in that case MN doesn't need RO at all (because CN doesn't
use MN's HoA to talk to MN).

> models. I believe I am going beyond the technicality of the issue
> here; I hope I am correct.:-)

That's what I'm not sure I understand: I'm not sure I understand the
technicality of the mechanism: does the MN _need_ at all to run MIP6 RO
HoT/I CoT/I when it uses a CoA instead of HoA...

If it's realized that MN needs to do RO then obviously a mechanism for
AAA to authorize RO service is necessary, IMHO.

Alex

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 04 Sep 2007 13:25:37 -0500

Hi Hannes,

I do not believe that the use of Route Optimization has to be authorized for
an MN. If the MN is capable of RO and initiates RO signaling, there is no
need for it to be authorized to do so.

The concern mentioned below is that operators prefer to be in control of an
MN. Since the HA is involved in the RO signaling, it can prevent the MN from
establishing route-optimized sessions with CNs.

-Raj

On 9/4/07 7:12 AM, "ext Hannes Tschofenig" <[email-masked]>
wrote:

> Does the group think that we need to provide any backend infrastructure
> support to enable this type of functionality?
> 
> Ciao
> Hannes
> 
>

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 04 Sep 2007 13:29:10 -0500

Hi Ahmad,

I am skeptical about the need for an MN being authorized to use an inherent
feature of MIP6. It makes no sense for an MN to be authorized depending on
the network that it is attached to whether it is able to use RO with CNs.

-Raj

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 4 Sep 2007 13:50:30 -0500

Hi Raj,
Please see comment inline.

Regards,
Ahmad

> I do not believe that the use of Route Optimization has to be 
> authorized for an MN. If the MN is capable of RO and 
> initiates RO signaling, there is no need for it to be 
> authorized to do so.
> 
> The concern mentioned below is that operators prefer to be in 
> control of an MN. Since the HA is involved in the RO 
> signaling, it can prevent the MN from establishing 
> route-optimized sessions with CNs.

[Ahmad]
MN may, by default, is authorized for RO as part of MIPv6 authorization.
On the other hand, some other operators may deny RO by default too.
However, an optional AVP to be returned in the MAM could make a big
difference and make the solution much more flexible and cleaner and
applicable on a per-user. As far as I know, at least one of the SDO's
has have some discussion on disallowing RO by default.

In summary, we either have a default authorization as part of MIPv6 for
all users or RO is NOT authorized by default for all users. That is
probably not the best choice. I believe we need to propose a solution
which is flexible and operator can choose one of the extremes or a
per-user authorization based on the operator service model.

All what is needed here is an extra optional AVP. Do you think that is
not worth it?

On the other hand, if HA is used to block the HoIT/HoT messages,
communicating that behavior to the HA can be based on a global policy, a
per domain, or per-user. But, since HA is going to H-AAA anyway why do
not we make that dynamic and supported as part of the Diameter MIPv6
Application.

Best Regards,
Ahmad

> > during his review of "Diameter Mobile IPv6: HA<->AAA" Ahmad 
> made the 
> > following
> > comment: 
> > 
> >>>> 
> > I did not see it included here?! As we discussed last time, 
> operators 
> > do care about having control over the willingness of the MN to have 
> > route optimization. If that the case, then there should be 
> a process 
> > to enable that kind of authorization. No?
> > <<<
> >

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 04 Sep 2007 21:34:20 +0200

Hi Raj,

you raise a good point. There is no doubt that a network operator can 
prevent all end hosts from using the RO procedure.

The main question therefore is whether the RO procedure has to enabled / 
disabled on a per user basis.

Ciao
Hannes

Basavaraj Patil wrote:
>>>> operators do care about having control over the willingness
>>>>         
>>> of the MN 
>>>       
>>>> to have route optimization. If that the case, then there
>>>>         
>>> should be a 
>>>

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 04 Sep 2007 14:54:54 -0500

Hi Ahmad,

Comments inline:

> On the other hand, some other operators may deny RO by default too.

Raj> Not sure what you mean by "other operators" above... Are you implying
that the visited network that the MN is attached to does not permit the MN
from using RO?
Fundamentally, what is the reasoning for preventing route-optimization. I
think there has not been any discussion about why RO should be blocked and
in what specific scenarios.

> has have some discussion on disallowing RO by default.

Raj> I think the HA can even today is capable of denying RO on a per-MN
granularity. I am just wondering what is the point of indicating to the MN
whether RO is permitted or not.
There has not been enough experience with RO and its implications. When is
RO triggered by an MN for example? IMO it makes no sense to build blocking
mechanisms for a feature that we do not have yet have better understanding.

And what is the point of denying RO. The MN can just as well use the CoA and
communicate directly with the CN. Session continuity does not exist in such
a case. But if the point of the operator was to ensure that all traffic
flows through the HA, that is already defeated via the CoA.

> all users or RO is NOT authorized by default for all users.

Raj> Whether RO can be achieved depends if the CN has the capability to
support RO as well. I don't see any benefit in having additional control of
a MIP6 feature. An MN may be able to perform RO with some CNs and not with
others. With this policy that you are proposing, does the indication to the
MN cause it to not do RO? And are you proposing policing that the MN does
not do RO via the HA? I just don't see good reasons for blocking RO at all.
I think this paranoia of maintaining control over a user by ensuring that
all traffic flows via an HA is not really justifiable.

> That is

Raj> It is not the question of whether it is just an extra AVP or a bit. I
think the premise of requiring authorization for RO is invalid (at least
IMO).

-Raj

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 4 Sep 2007 16:08:32 -0500

Hi Raj,

Regards,
Ahmad

> >> authorized for an MN. If the MN is capable of RO and initiates RO 
> >> signaling, there is no need for it to be authorized to do so.
> >> 
> >> The concern mentioned below is that operators prefer to be 
> in control 
> >> of an MN. Since the HA is involved in the RO signaling, it can 
> >> prevent the MN from establishing route-optimized sessions with CNs.
> > 
> > [Ahmad]
> Raj> Not sure what you mean by "other operators" above... Are you 
> Raj> implying
> that the visited network that the MN is attached to does not 
> permit the MN from using RO?
> Fundamentally, what is the reasoning for preventing 
> route-optimization. I think there has not been any discussion 
> about why RO should be blocked and in what specific scenarios.
> 
> granularity. 

[Ahmad]
Yes. Of course that is part of HA capabilities. However, the point is:
how the HA decides which user RO to block.

> I am just wondering what is the point of 
> indicating to the MN whether RO is permitted or not.
> There has not been enough experience with RO and its 
> implications. When is RO triggered by an MN for example? IMO 
> it makes no sense to build blocking mechanisms for a feature 
> that we do not have yet have better understanding.

[Ahmad]
There are two points here and let me address both together.

1. Hmm, you are raising a good point here on how to indicate that to the
MN. I guess indicating that to the MN could be optional, however, the HA
will enforce this policy on a per-user basis without any statically
configured information. i.e. during MIPv6 authorization. Freebee:-)

BTW: Since some people may not like the idea of another AVP, this can be
as simple as a bit in the MIPv6-Feature-Vector, which, as per Diameter
MIP6 application, is included in all Requests and Answers messages!

2. I agree there have not been a lot of discussion on RO
authorization/blocking but let us think of it in a different way. What
about if we say that a home network is interested in getting some users
traffic pass through its home network all the time. For whatever reason.
They may be able to negotiate a better roaming deal!:-)

> 
> And what is the point of denying RO. The MN can just as well 
> use the CoA and communicate directly with the CN. Session 
> continuity does not exist in such a case. But if the point of 
> the operator was to ensure that all traffic flows through the 
> HA, that is already defeated via the CoA.

[Ahmad]
But let us take what RFC3775 says in this regard. A CN is not supposed
to trust a MN unless it is able to verify that the MN is addressable at
the claimed HoA and CoA. Now, if CN does not behave, that in itself a
violation of RFC3775 and a risk the CN is taking and should consider
seriously. Right?

Here RFC3775 text:
"
5.2.5.  Return Routability Procedure

   The Return Routability Procedure enables the correspondent node to
   obtain some reasonable assurance that the mobile node is in fact
   addressable at its claimed care-of address as well as at its home
   address.  Only with this assurance is the correspondent node able to
   accept Binding Updates from the mobile node which would then instruct
   the correspondent node to direct that mobile node's data traffic to
   its claimed care-of address.
"
> 
> > 
> > In summary, we either have a default authorization as part of MIPv6 
> > for all users or RO is NOT authorized by default for all users.
> 
> support RO as well. I don't see any benefit in having 
> additional control of a MIP6 feature. An MN may be able to 
> perform RO with some CNs and not with others. With this 
> policy that you are proposing, does the indication to the MN 
> cause it to not do RO? And are you proposing policing that 
> the MN does not do RO via the HA? I just don't see good 
> reasons for blocking RO at all.

[Ahmad]
I see your point, but as far as blocking RO all together, I guess I
heard people talking about it before!

> I think this paranoia of maintaining control over a user by 
> ensuring that all traffic flows via an HA is not really justifiable.

[Ahmad]
May be it is; if those marketing guys find a way to make money out of
it. You never know:-)
However, if people think that it is not a good idea despite all
simplicity proposed here, "just adding a bit in MIP6-Feature-Vector",
then that is how things is decided here anyway. My recollection, if I
still remember correctly, there was some support for this long time ago
after the Nov. 2006 IETF meeting, I guess.

> Raj> It is not the question of whether it is just an extra 
> AVP or a bit. 
> Raj> I
> think the premise of requiring authorization for RO is 
> invalid (at least IMO).
> 
> -Raj
> 
> > 
> > communicating that behavior to the HA can be based on a 
> global policy, 
> > a per domain, or per-user. But, since HA is going to H-AAA 
> anyway why 
> > do not we make that dynamic and supported as part of the Diameter 
> > MIPv6 Application.
> > 
> > Best Regards,
> > Ahmad
> > 
> >> 
> >> -Raj
> >> 
> >>

---

From: Brian Haley <[email-masked]>
Date: Tue, 04 Sep 2007 21:27:17 -0400

> violation of RFC3775 and a risk the CN is taking and should consider

To the other end it's just an address, not a CoA - direct communication 
without mobility support.

I agree with Raj and see no purpose to not authorizing RO.  Do we really 
want to cripple Mipv6 before it even gets deployed?

-Brian

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 4 Sep 2007 23:18:21 -0500

> Right, and in that case MN doesn't need RO at all (because CN 
> doesn't use MN's HoA to talk to MN).
> 
> That's what I'm not sure I understand: I'm not sure I 
> understand the technicality of the mechanism: does the MN 
> _need_ at all to run MIP6 RO HoT/I CoT/I when it uses a CoA 
> instead of HoA...

[Ahmad]
Hi Alex,

To be honest, it is really confusing:-(
It seems to me that one opinion argues that we need to support Mobile
IPv6 including RO and we should not kill it before it is even deployed
by skinning off the RO from MIPv6; which I strongly agree. However, when
it is pointed out that as per RFC3775 the CN is supposed to make sure
that the MN is addressable at the HoA and CoA before even trusting this
MN, another opinion says, as you just mentioned above:-), the CoA is
just another IP address. Which absolutely fine. However, we MUST not
pick and choose. Either we support RFC3775 as a whole or just let us
deploy what is meaningful. As far as I remember, I heard that some SDO's
do not want to support RO at least one year back.

> 
> If it's realized that MN needs to do RO then obviously a 
> mechanism for AAA to authorize RO service is necessary, IMHO.

[Ahmad]
Agreed!

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 4 Sep 2007 23:28:12 -0500

> > to trust a MN unless it is able to verify that the MN is 
> addressable 
> > at the claimed HoA and CoA. Now, if CN does not behave, 
> that in itself 
> > a violation of RFC3775 and a risk the CN is taking and 
> should consider 
> > seriously. Right?
> 
> To the other end it's just an address, not a CoA - direct 
> communication without mobility support.

[Ahmad]
Why the MN needs to ask for MIPv6 then. It could negotiate Simple IPv6
and that is perfectly fine.
> 
> I agree with Raj and see no purpose to not authorizing RO.  
> Do we really want to cripple Mipv6 before it even gets deployed?

[Ahmad]
Hi Brian,

Not at all, I am not proposing to cripple MIPv6 before it even gets
deployed, I am just asking that we need to comply with RFC3775 which is
the basis of MIPv6. If we start the process of pick and choose, then I
am afraid we are contributing to the crippling of MIPv6. As I said, CN
is not supposed to trust a MN until it is able to verify that the MN is
addressable at both addresses and that address is referred to in RFC3775
as the CoA. If we disagree with RFC3775, then we probably need to change
it. IMHO.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 05 Sep 2007 13:34:05 +0200

Ahmad Muhanna wrote:
>>> I guess allowing the Home Network the option to force user
>>> traffic through the home network, IMO, makes a good business case
>>> and a flexibility for the operator to use for offering different
>>> service models. I believe I am going beyond the technicality of
>>> the issue here; I hope I am correct.:-)
>> That's what I'm not sure I understand: I'm not sure I understand
>> the technicality of the mechanism: does the MN _need_ at all to run
>> MIP6 RO HoT/I CoT/I when it uses a CoA instead of HoA...
> 
> [Ahmad] Hi Alex,
> 
> To be honest, it is really confusing:-( It seems to me that one
> opinion argues that we need to support Mobile IPv6 including RO and
> we should not kill it before it is even deployed by skinning off the
> RO from MIPv6; which I strongly agree. However, when it is pointed
> out that as per RFC3775 the CN is supposed to make sure that the MN
> is addressable at the HoA and CoA before even trusting this MN,
> another opinion says, as you just mentioned above:-), the CoA is just
> another IP address. Which absolutely fine. However, we MUST not pick
> and choose. Either we support RFC3775 as a whole or just let us 
> deploy what is meaningful. As far as I remember, I heard that some
> SDO's do not want to support RO at least one year back.

It would be interesting to learn from these SDOs how exactly would they 
like to not support RO:

-by not implementing RO software in their HA?
-by IP filtering rules at HA? (drop HoT/I)?
-by advertising lack-RO in their advertisements to MN?
-by AAA means?

Alex

>> If it's realized that MN needs to do RO then obviously a mechanism
>> for AAA to authorize RO service is necessary, IMHO.
> 
> [Ahmad] Agreed!
> 
>> Alex
>> 
>> 
>>  This email has been scanned by the MessageLabs Email Security
>> System. For more information please visit 
>> http://www.messagelabs.com/email

---

From: Brian Haley <[email-masked]>
Date: Wed, 05 Sep 2007 10:25:01 -0400

Hi Ahmad,

> and that is perfectly fine.

I think you mis-understood me, I wasn't talking about using MIPv6.  A MN 
can use the IPv6 address it's configured on the remote link for 
communicating with local nodes (eg DNS) without using any MIPv6 
functionality.  It should reverse-tunnel the rest.  But if we start 
restricting RO, people will start getting creative with their 
implementations and work around it, and none of those will be 
inter-operable.

Jouni's latest email clarified what he meant, but I still don't agree an 
HA RO knob should exist, that's just my opinion.

-Brian

---

From: <[email-masked]>
Date: Wed, 5 Sep 2007 17:54:23 +0200

Hi Brian,

> I think you mis-understood me, I wasn't talking about using 
> MIPv6.  A MN can use the IPv6 address it's configured on the 
> remote link for communicating with local nodes (eg DNS) 
> without using any MIPv6 functionality.  It should 
> reverse-tunnel the rest.  But if we start restricting RO, 
> people will start getting creative with their implementations 
> and work around it, and none of those will be inter-operable.

A MN needs to be prepared for failing return routability test
anyway.. there might be an evil firewall in between than causes
the RO to fail. So if the MN does not know whether the HA or
some other intermediate node failed the RO, there is not much
point of trying to do clever things in the MN. Having said this
I think there is no need to explicitly tell the MN whether HA
does some policy based decision on RO. The MN will learn it
eventually..

> Jouni's latest email clarified what he meant, but I still 
> don't agree an HA RO knob should exist, that's just my opinion.

Unfortunately I think operators will do it in any case. They
are creative on that ;) And sometimes also forced by regulation.
Doing such policy decision in a HA is more logical place than
trying to do that in a cluster of firewalls.

Cheers,
	Jouni

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 05 Sep 2007 16:02:07 -0500

Hi Jouni,

I agree with your comments about the many reasons why RO may fail
(firewalls, CN being incapable, HA policy etc.).

So I do not think there is any need to specify the RO authorization knob for
MIP6.

And I do agree that operators will do all sorts of creative things to
prevent RO (if that is what they want). But there is no reason for it to
specified.

-Raj

---

From: "DE JUAN HUARTE FEDERICO" <[email-masked]>
Date: Thu, 6 Sep 2007 09:49:00 +0200

Hi,

for what is worth, my opinion is that given that it is aknowledged that network administrators may want to disallow/block RO, this should be reason enough to specify it
What is the harm of notifying "RO not supported" to the MN?

I see a difference between:
   1- RO does not work because network topology or other reasons
   2- RO does not work because of administrative decision
The first case is (arguably) an error condition and should be (potentially) corrected
The second case is a desired behaviour

There seem to be already mechanisms to block RO (are they documented?), but what's the MN experience in these conditions?
I assume that the MN just experiences a timeout. In a typical implementation this would lead to a retry and eventually to consider this as an error condition
The implementation in the MN can be cleaner when there's a proper notification of RO not supported

Regards

federico

-----Message d'origine-----
De : Basavaraj Patil [mailto:[email-masked]] 
Envoyé : mercredi 5 septembre 2007 23:02
À : ext [email-masked]; [email-masked]; [email-masked]
Cc : [email-masked]; [email-masked]
Objet : Re: [Mip6] Diameter Mobile IPv6 Bootstrapping: AuthorizingRouteOptimization

Hi Jouni,

I agree with your comments about the many reasons why RO may fail (firewalls, CN being incapable, HA policy etc.).

So I do not think there is any need to specify the RO authorization knob for MIP6.

And I do agree that operators will do all sorts of creative things to prevent RO (if that is what they want). But there is no reason for it to specified.

-Raj

On 9/5/07 10:54 AM, "ext [email-masked]" <[email-masked]>
wrote:

>> I think you mis-understood me, I wasn't talking about using MIPv6.  A 
>> MN can use the IPv6 address it's configured on the remote link for 
> A MN needs to be prepared for failing return routability test anyway.. 
> there might be an evil firewall in between than causes the RO to fail. 
> So if the MN does not know whether the HA or some other intermediate 
> node failed the RO, there is not much point of trying to do clever 
> things in the MN. Having said this I think there is no need to 
> explicitly tell the MN whether HA does some policy based decision on 
> RO. The MN will learn it eventually..
> 
>> Jouni's latest email clarified what he meant, but I still don't agree 
>> an HA RO knob should exist, that's just my opinion.
> 
> Unfortunately I think operators will do it in any case. They are 
> creative on that ;) And sometimes also forced by regulation.
> Doing such policy decision in a HA is more logical place than trying 
> to do that in a cluster of firewalls.
> 
> 
> Cheers,
> Jouni
> 
>> 
>> -Brian
>>

---

From: <[email-masked]>
Date: Thu, 6 Sep 2007 10:17:52 +0200

Hi federico,

> Sent: Thursday, September 06, 2007 10:49 AM

>    2- RO does not work because of administrative decision The 
> first case is (arguably) an error condition and should be 
> (potentially) corrected The second case is a desired behaviour

Even if the MN knew something about administrative decision, it
still must prepare for failing RO. Even if the mobility service
provider allows RO others between the MN and a CN may block RO.

> There seem to be already mechanisms to block RO (are they 
> documented?), but what's the MN experience in these conditions?
> I assume that the MN just experiences a timeout. In a typical 

RO times out and the MN "falls back" to reverse tunneled mode.
No need for anything more advanced. RO is just an optimization.
Note that the MN has connectivity all the time so it is not
really an error case if RO fails.

> implementation this would lead to a retry and eventually to 
> consider this as an error condition The implementation in the 
> MN can be cleaner when there's a proper notification of RO 
> not supported

I don't think there is a need for suck notification. 

Cheers,
	Jouni

> De : Basavaraj Patil [mailto:[email-masked]] Envoyé 
> : mercredi 5 septembre 2007 23:02 À : ext 
> [email-masked]; [email-masked]; 
> [email-masked] Cc : [email-masked]; [email-masked] Objet : 
> Re: [Mip6] Diameter Mobile IPv6 Bootstrapping: 
> AuthorizingRouteOptimization
> 
> 
> Hi Jouni,
> 
> I agree with your comments about the many reasons why RO may 
> fail (firewalls, CN being incapable, HA policy etc.).
> 
> And I do agree that operators will do all sorts of creative 
> things to prevent RO (if that is what they want). But there 
> is no reason for it to specified.
> 
> -Raj
> 
> 
> don't agree

---

From: <[email-masked]>
Date: Thu, 6 Sep 2007 10:20:00 +0200

Hi Raj,

"no reason for it to specified" will just lead to so many times
seen creativeness on AAA interfaces in other SDOs. I don't think
that will benefit anyone..  at least those who end up deploying
these backend AAA systems.

Cheers,
	Jouni

> -----Original Message-----
> From: Basavaraj Patil [mailto:[email-masked]] 
> Sent: Thursday, September 06, 2007 12:02 AM
> To: ext [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [Dime] Re: [Mip6] Diameter Mobile IPv6 
> Bootstrapping: Authorizing RouteOptimization
> 
> 
> 
> Hi Jouni,
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 6 Sep 2007 07:49:18 -0500

Federico,

Excellent! & I fully Agree! 

Regards,
Ahmad

> From: DE JUAN HUARTE FEDERICO 
> [mailto:[email-masked]] 
> Sent: Thursday, September 06, 2007 2:49 AM
> To: Basavaraj Patil; [email-masked]; Muhanna, Ahmad (RICH1:2H10)
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [Mip6] Diameter Mobile IPv6 Bootstrapping: 
> for what is worth, my opinion is that given that it is 
> aknowledged that network administrators may want to 
> disallow/block RO, this should be reason enough to specify it

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 6 Sep 2007 07:58:29 -0500

Hi Jouni,

Actually after the nice description by Federico, I am thinking why not informing the MN. If we mimic MIPv4, for example, I remember there is a code of value "I think it is 1", which means successful registration BUT Simultaneous Binding is not allowed.

Can we say that after the HA receives the AAA indication about RO, would returning a code such like this one to let the MN know that Registration is successful, however, RO is not Allowed; is possible?

For backward compatibility, for example, code 0 still can be used to mean that Registration is successful and RO is Allowed, as it is now.

It is actually amazing and I never though that it could be as simple and harmless as it is now.

One bit in MIP6-Feature-Victor between the HA and AAA and another status code between the HA and MN.
All-in-All less than 2 lines.

My 2 cents.

Regards,
Ahmad

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Thursday, September 06, 2007 3:18 AM
> To: [email-masked]; 
> [email-masked]; [email-masked]; Muhanna, Ahmad 
> (RICH1:2H10)
> Subject: RE: [Mip6] Diameter Mobile IPv6 
> Bootstrapping:AuthorizingRouteOptimization
> 
> Hi federico,
> 
> >    2- RO does not work because of administrative decision The first 
> > case is (arguably) an error condition and should be
> Even if the MN knew something about administrative decision, 
> it still must prepare for failing RO. Even if the mobility 
> service provider allows RO others between the MN and a CN may 
> block RO.
> 
> consider 
> > this as an error condition The implementation in the MN can 
> be cleaner 
> > when there's a proper notification of RO not supported
> 
> > : mercredi 5 septembre 2007 23:02 À : ext [email-masked]; 
> > [email-masked]; [email-masked] Cc : [email-masked]; 
> > [email-masked] Objet :
> things to 
> > prevent RO (if that is what they want). But there is no 
> reason for it 
> > to specified.
> > 
> > -Raj
> > 
> >

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 18 Sep 2007 22:33:51 -0700

Hi Hannes,

> support to enable this type of functionality?

IMO, it is not needed.

Regards
Vijay

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Thu, 20 Sep 2007 12:04:04 -0400

I think it is needed. Primarily because the decision to authorize or
de-authorize RO (RR signaling) should be taken in the AAA infrastructure
based on several factors including user's subscription data.

BR,
Kuntal

> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: Wednesday, September 19, 2007 12:34 AM
> To: Hannes Tschofenig
> Cc: Mobile IPv6 Mailing List; [email-masked]
> Subject: Re: [Dime] Diameter Mobile IPv6 Bootstrapping: Authorizing
> RouteOptimization
> 
> Hi Hannes,
> 
> Hannes Tschofenig wrote:
> > Hi all,
needed.
> > I did not see it included here?! As we discussed last time,
operators do
> > Does the group think that we need to provide any backend
infrastructure