Subject: [MEXT] Reactive mobility agent for the CN which doesn't support RO function

From: Xiangsong Cui <[email-masked]>
Date: Wed, 07 Jul 2010 11:55:52 +0800

Hello all,

We (Antti Makela and me) ever submitted a draft in netext wg,
http://tools.ietf.org/id/draft-cui-netext-route-optimization-agent-ext-02.txt,
but now, after some discussion, we think that the approach is in the scope of mext.

The main idea is:

1, A mobile node (taking the MN role) tries to set up route optimization communication with another node (taking the CN role);
2, The CN doesn't support MIP6 or RO function (in normal case, the RO attempt would be failed);
3, This draft introduce a functional entity which can take over the RO attempt on behalf of CN, so the MN can set up RO 
communication with the peer, although the CN doesn't support that;
4, The functional entity is like a reactive mobility agent, which may be implemented in AR or MR of the CN;
5, MIP is used between the MN and the reactive mobility agent of CN and the protocol between CN and the reactive mobility agent is 
simple IP;
6, Both the MN and the CN can get benefit from this approach (less transport delay and others).

What do you think about this idea?
If that should build interest, we would re-submit the draft (with necessary modification) in MEXT working group.

Any comments are appreciated.

Thanks and best regards,
Xiangsong

---

From: [email-masked] (Arnaud Ebalard)
Date: Wed, 07 Jul 2010 18:08:21 +0200

Hi,

Xiangsong Cui <[email-masked]> writes:

> 1, A mobile node (taking the MN role) tries to set up route
> optimization communication with another node (taking the CN role); 
> 3, This draft introduce a functional entity which can take over the RO
> attempt on behalf of CN, so the MN can set up RO communication with
> the peer, although the CN doesn't support that;
> 5, MIP is used between the MN and the reactive mobility agent of CN
> and the protocol between CN and the reactive mobility agent is simple
> IP;
> If that should build interest, we would re-submit the draft (with
> necessary modification) in MEXT working group. 
>

No time to read the draft but from the summary above, this has
similarities with the idea of Correspondent Router presented in:

http://tools.ietf.org/html/draft-bernardos-mext-nemo-ro-cr-00

Cheers,

a+

---

From: Xiangsong Cui <[email-masked]>
Date: Thu, 08 Jul 2010 10:26:51 +0800

Hi Arnaud,

Thanks for your response!

I had a quick read on the nemo-ro-cr-draft, and I think they are different approach, let me clarify the differences.

The route optimization in nemo-ro-cr-draft is initiated by the MR and destined to the CR;
section 4 reads "The process of NEMO RO set-up MUST be initiated by the MR"
section 4.2 reads "Prior to the binding establishment and tunnel set-up between an MR and a CR, the MR MUST find out whether there 
exist a CR that...... "
and section 4.3 reads "Once the MR has learnt the IPv6 address of a CR that can be used to route optimise some traffic, it needs to 
perform the Binding Registration to this CR."

while in my draft the route optimization is initiated by the MN and destined to the CN.
This means, the MN sends RO related messages to the address of CN and when the MN receives response messages, it takes the messages 
as sent by the CN.
So in the side of MN, this is just a normal route optimization procedure as defined in RFC3775 (without CR discovery and other 
operations), while in the side of CN, the reactive agent intercepts RO related messages and assists setting up route optimization 
for the CN.

There are also some other differences, such as nemo-ro-cr-draft introduces new option, while my draft need no new mobility messages 
or options.

Does this make sense?

Thanks again and regards
Xiangsong

----- Original Message ----- 
From: "Arnaud Ebalard" <[email-masked]>
To: "Xiangsong Cui" <[email-masked]>
Cc: "Antti Mäkelä" <[email-masked]>; "mext" <[email-masked]>
Sent: Thursday, July 08, 2010 12:08 AM
Subject: Re: [MEXT] Reactive mobility agent for the CN which doesn't support RO function

> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext

---

From: [email-masked] (Arnaud Ebalard)
Date: Thu, 08 Jul 2010 14:04:08 +0200

Xiangsong Cui <[email-masked]> writes:

> I had a quick read on the nemo-ro-cr-draft, and I think they are
> different approach, let me clarify the differences. 
>
> section 4.2 reads "Prior to the binding establishment and tunnel
> set-up between an MR and a CR, the MR MUST find out whether there
> exist a CR that...... "
> and section 4.3 reads "Once the MR has learnt the IPv6 address of a CR
> that can be used to route optimise some traffic, it needs to perform
> the Binding Registration to this CR."
>
> This means, the MN sends RO related messages to the address of CN and
> when the MN receives response messages, it takes the messages as sent
> by the CN.
> So in the side of MN, this is just a normal route optimization
> procedure as defined in RFC3775 (without CR discovery and other
> operations), while in the side of CN, the reactive agent intercepts RO
> related messages and assists setting up route optimization for the CN.
>
> There are also some other differences, such as nemo-ro-cr-draft
> introduces new option, while my draft need no new mobility messages or
> options.
>
> Does this make sense?

I think, yes. 

a+

---

From: Jean-Michel Combes <[email-masked]>
Date: Thu, 8 Jul 2010 17:44:31 +0200

Hi,

2010/7/7 Xiangsong Cui <[email-masked]>:
> 1, A mobile node (taking the MN role) tries to set up route optimization
> communication with another node (taking the CN role);
> attempt on behalf of CN, so the MN can set up RO communication with the
> peer, although the CN doesn't support that;
> 5, MIP is used between the MN and the reactive mobility agent of CN and the
> protocol between CN and the reactive mobility agent is simple IP;

IMHO, you are playing with fire :)
More seriously:
- Modification of data packets by the ROA
Your proposal can break the E2E security between the MN and the CN
(e.g. if IPsec/AH is used between the MN and the CN)
- Source address modification in RO signaling packets by the ROA
If mechanisms preventing IP spoofing (e.g. SAVI) are deployed close to
the ROA, the RO signaling packets sent by the ROA could be discarded.

Best regards.

JMC.

---

From: Xiangsong Cui <[email-masked]>
Date: Fri, 09 Jul 2010 12:21:27 +0800

Hi Jean,

Thanks you for your review and comments!

My clarification inline.

> (e.g. if IPsec/AH is used between the MN and the CN)

This is a very good comment!
It remind me of another question, if the comminication between MN and CN is protected by IPsec/AH, can MN set up route optimization 
with CN (CN supports MIP and RO function)?
In my understanding, since MN changes its source IP address (HoA=>CoA), so optimized communication can't be established, right?

If that was true, then we can get a more clear picture:
Case 1, communication between MN and CN is protected by IPsec/AH, then no Route Optimization;
Case 2, communication between MN and CN is NOT protected by IPsec/AH, then:
    case 2a, if CN does support MIP or RO function, then RFC3775 applies for Route Optimization,
    case 2b, if CN does NOT support MIP or RO function, then Route-Optimization-Agen may be considered for Route Optimization?

Do I make mistake?

> the ROA, the RO signaling packets sent by the ROA could be discarded.

Yes, if there is such mechanism, then the return routability test would failed, and the RO attempt is also failed, this does not 
impact the normal communication. I mean, MN tries, ROA tries, but all these are not harmful.
If there is no such mechanism in the network, MN tries, and ROA tries, and they would succeed, the route optimization would be 
established.
This means, the ROA approach would be useful in some environment, and would be helpless and hurtless in other environment, right?

I would like to address these comments and add more clarification in the next version.

Thanks again and best regards
Xiangsong

---

From: Xiangsong Cui <[email-masked]>
Date: Fri, 09 Jul 2010 12:22:18 +0800

Hi Arnaud,

Thank you for your feedback!

best regards,
Xiangsong

---

From: Jean-Michel Combes <[email-masked]>
Date: Fri, 9 Jul 2010 09:58:09 +0200

2010/7/9 Xiangsong Cui <[email-masked]>:
> It remind me of another question, if the comminication between MN and CN is
> protected by IPsec/AH, can MN set up route optimization with CN (CN supports
> MIP and RO function)?

Yes, MN can use RO.

> In my understanding, since MN changes its source IP address (HoA=>CoA), so
> optimized communication can't be established, right?

The "real" source address is the HoA (that's the philosophy of MIPv6
:)) and the IPsec SAs are based on the HoA. So, optimized
communication can be established.

>   case 2b, if CN does NOT support MIP or RO function, then
> Route-Optimization-Agen may be considered for Route Optimization?
>
> Do I make mistake?

IMHO, yes: Case 1 is wrong (cf. my previous comment). MN can (MUST be
able to) use RO in every case and in case 1, your proposal will break
the E2E security.

> Yes, if there is such mechanism, then the return routability test would
> failed, and the RO attempt is also failed, this does not impact the normal
> communication. I mean, MN tries, ROA tries, but all these are not harmful.
> If there is no such mechanism in the network, MN tries, and ROA tries, and
> they would succeed, the route optimization would be established.
> This means, the ROA approach would be useful in some environment, and would
> be helpless and hurtless in other environment, right?

I agree.

Best regards.

JMC.

---

From: Antti Mäkelä <[email-masked]>
Date: Fri, 9 Jul 2010 11:14:16 +0300 (EEST)

> able to) use RO in every case and in case 1, your proposal will break

   I'm not sure if it's actually wrong. End-to-end security associations 
are established between HoA's, right?

   Now, in case of proxy mobile IP, the only address that the Basic 
IP-capable node gets (in the draft, MN2), is the "HoA" that MAG 
administers.

   Thus, the MN2 does not actually have a CoA at all. Endpoint SA is 
created from MN1's HoA to MN2's only IP address (or HoA). MN1 handles 
HoA<->CoA association and route optimization by itself, MAG does the same 
thing on behalf of MN2. So this should only affect routing, not end-host 
addressing.

   Right?

--
- Antti Mäkelä | Researcher -
- Department of communications and networking -
- Aalto University -

---

From: Jean-Michel Combes <[email-masked]>
Date: Fri, 9 Jul 2010 11:00:23 +0200

Hi again,

> This is a very good comment!

In fact, this is not a good comment :(
E2E security is not broken: AH ICV is correct when the data packet is
checked by the IPsec stack.

Sorry for the noise ...

Best regards.

JMC.

---

From: Jean-Michel Combes <[email-masked]>
Date: Fri, 9 Jul 2010 11:17:27 +0200

2010/7/9 Antti Mäkelä <[email-masked]>:
>>>   case 2a, if CN does support MIP or RO function, then RFC3775 applies
>>> for
>>> Route Optimization,
>  I'm not sure if it's actually wrong.

As said in my last reply, I agree now that E2E security is not broken.

> End-to-end security associations are
> established between HoA's, right?

Yes.

>
>  Now, in case of proxy mobile IP, the only address that the Basic IP-capable
> node gets (in the draft, MN2), is the "HoA" that MAG administers.
>
>  Thus, the MN2 does not actually have a CoA at all. Endpoint SA is created
> from MN1's HoA to MN2's only IP address (or HoA). MN1 handles HoA<->CoA
> association and route optimization by itself, MAG does the same thing on
> behalf of MN2. So this should only affect routing, not end-host addressing.
>
>  Right?

I must admit I didn't look at PMIPv6 case (as we are on mext ML and
not on netlmm/netext ML :)).

Best regards.

JMC.

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Sat, 24 Jul 2010 21:31:42 +0200

Hi,

> http://tools.ietf.org/html/draft-bernardos-mext-nemo-ro-cr-00

Admitting that I have not yet read your draft (I'm just catching up
while getting to Maastricht), I think there are also some ideas somehow
similar to de idea of Proxy-MR:

http://tools.ietf.org/html/draft-bernardos-mext-miron-00

Thanks (apologies for this very late comment),

Carlos

-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

---

From: Xiangsong Cui <[email-masked]>
Date: Mon, 26 Jul 2010 14:41:57 +0800

I guess the mail is lost, so re-post it.
sorry for the duplication.

Best Regards

Xiangsong

----- 原邮件 -----
发件人: Xiangsong Cui <[email-masked]>
日期: 星期日, 七月 25日, 2010 下午11:33
主题: 回复:Re: [MEXT] Reactive mobility agent for  the CN which doesn't support RO function
收件人: [email-masked]
抄送: Arnaud Ebalard <[email-masked]>,Antti M?kel? <[email-masked]>,mext <[email-masked]>

> Hi Carlos,
> 
> Many thanks for your feedback,
> 
> I have read your draft and I agree they are similar approaches, 
> but different.
> 
> Your draft is about the scenario where the Proxy of a RO-unable 
> node initiates a route optimization to the peer-endpoint, while in 
> my draft it is about the scenario where the Proxy of a RO-unable 
> node reflects a route optimization initiated by the peer-endpoint.
> 
> In other words, the route optimization is *directional*, from the 
> initiator (i.e. the MN role of RFC3775) to the reflector (i.e. the 
> CN role of RFC3775), right?
> 
> In your draft, it is about a proxy of the initiator, who initiates 
> the route optimization, and MNN's HA is avoided;
> in my draft, it is about a proxy of the reflector, who reflects 
> the route optimization, and the peer's HA is avoided.
> The effect is almost equal.
> 
> 
> Best Regards
> Xiangsong
> 
> ----- 原邮件 -----
> 发件人: Carlos Jesús Bernardos Cano <[email-masked]>
> 日期: 星期日, 七月 25日, 2010 上午5:31
> 主题: Re: [MEXT] Reactive mobility agent for the CN which doesn't 
> support RO function
> 收件人: Arnaud Ebalard <[email-masked]>
> 抄送: Xiangsong Cui <[email-masked]>, Antti M?kel? 
> <[email-masked]>, mext <[email-masked]>
> 
> > Hi,
> > 
> > > > but now, after some discussion, we think that the approach 
> is 
> > in the scope of mext.
> > > >
> > > > The main idea is:
> > > >
> > > > 2, The CN doesn't support MIP6 or RO function (in normal 
> case, 
> > the RO
> > > > attempt would be failed); 
> > > > attempt on behalf of CN, so the MN can set up RO 
> communication 
> > with> > the peer, although the CN doesn't support that;
> > > > 4, The functional entity is like a reactive mobility agent, 
> > which may
> > > > be implemented in AR or MR of the CN; 
> > > > 5, MIP is used between the MN and the reactive mobility 
> agent 
> > of CN
> > > > and the protocol between CN and the reactive mobility agent 
> is 
> > simple> > IP;
> > > > 6, Both the MN and the CN can get benefit from this approach 
> (less> > > transport delay and others). 
> > > >
> > > >
> > > > If that should build interest, we would re-submit the draft 
> (with> > > necessary modification) in MEXT working group. 
> > > >
> > while getting to Maastricht), I think there are also some ideas 
> > somehowsimilar to de idea of Proxy-MR:
> >

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 26 Jul 2010 09:44:13 +0200

Hi Xiangsong,

Yes, the approaches look similar, though the problem they address is
different, as you mentioned.

Thanks,

Carlos

On Sun, 2010-07-25 at 23:33 +0800, Xiangsong Cui wrote:
> I have read your draft and I agree they are similar approaches, but different.
> 
> Your draft is about the scenario where the Proxy of a RO-unable node initiates a route optimization to the peer-endpoint, while in my draft it is about the scenario where the Proxy of a RO-unable node reflects a route optimization initiated by the peer-endpoint.
> 
> In other words, the route optimization is *directional*, from the initiator (i.e. the MN role of RFC3775) to the reflector (i.e. the CN role of RFC3775), right?
> 
> In your draft, it is about a proxy of the initiator, who initiates the route optimization, and MNN's HA is avoided;
> in my draft, it is about a proxy of the reflector, who reflects the route optimization, and the peer's HA is avoided.
> 主题: Re: [MEXT] Reactive mobility agent for the CN which doesn't support RO function
> 抄送: Xiangsong Cui <[email-masked]>, Antti M?kel? <[email-masked]>, mext <[email-masked]>
> 
> > Hi,
> > 
> > > > 2, The CN doesn't support MIP6 or RO function (in normal case, 
> > the RO
> > > > attempt on behalf of CN, so the MN can set up RO communication 
> > > > and the protocol between CN and the reactive mobility agent is 
> > simple> > IP;