Subject: RE: [nemo] RE: RO between MR and CN

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Tue, 19 Oct 2004 18:57:03 +0200

Hi Carlos :)

Is the MIRON document already published in a final form or does it make sense to provide feed back for lower interest things like typos? For the time being, let me discuss concepts.

> > Hi,
> >
> > On Wed, 13 Oct 2004 13:34:06 +0200,
> > "Pascal Thubert (pthubert)" <[email-masked]> wrote:
> >
> > > Hi Tania
> > >
> > > I was thinking things like of snooping. MR might intercept all packets to LFN, recognize
> a HoT and keep it. I remember discussing that with Alex long ago... Anyway, we try to say
> "don't take that path" as opposed to describe a solution in details.
> >
> > I don't think its possible to provide RO while keeping the RR function
> > of MIPv6 untouched.  It would probably require modification of the
> > packet at MR to use the HoA opt and the routing header for every
> > packet, if we want to keep the MIPv6 spec as is.
> 
> 	Yes, one possible solution is the MR performing all the RR and RO
> signalling on behalf of the LFNs of the NEMO, in order to provide RO for
> LFNs that are communicating to CNs outside the NEMO. This is actually
> the solution we have proposed in MIRON (see my previous e-mail if you
> want a pointer to it), so the MR, as you said, has to process the
> packets sent/received by a LFN in order to insert HoA DO/remove RH. I
> agree that it could have some performance concerns if the process is
> performed to every LFN-CN "flow", but as we have already discussed in a
> previous thread, some mechanism should be used to perform the RO in a
> reasonable way.

There are 2 aspects to the proposal, even if (like ORC) it's packaged as one. The first aspect is the proxying for the MNN. The second is obtaining a topologically correct CoA via DHCP.

1) proxying

As we say in this thread, we discussed that on the ML, at least Alex and I, and there are some identified protential problems to the approach (that might be worth more text in the taxonomy?) that you might have to deal with:

1a) MNN is VMN
	If the MNN is a visitor that handles its own mobility and RO, the MR might in fact act as an attacker (against its will :). CoT messages might clash, and if the MN moves away, the MR might keep the CN binding improperly

1b) MNN has an SA with CN
	For instance, CN is a VPN entry point for MNN, and MNN handles its own IPSEC. Manipulating packets on the fly will cause them to be dropped.

1c) Snooping for CoT
	MR has to snoop packets to the MNN in order to find CoT. This defeats the very purpose of the test (collocation). So if the test is improved in some future, it might not work anymore. And it's pretty dirty, reading someone else's packets, isn't it :) ?

1d) modifying packets on the fly
	Too bad MIP RO to CN is based on Home addr option as opposed to tunnels, which does not seem to be an option. The MR has to match source AND destination in order to find whether it can do RO to the CN. And then it has to insert the option, which might be a painful operation (apparently more costly then tunnelling, which is already hardware assisted in some boxes). 
In short, it is going to be software routed for quite some time.

2) CoA

Getting the CoA from the TOP has also been discussed in the ML. As you point out, there are approaches based on PD, like draft-leekj-nemo-ro-pd-02.txt but also draft-droms-nemo-dhcpv6-pd-01.txt. There's also, closer to your proposal, a proxy ND based proposal draft-jeong-nemo-ro-ndproxy-02.txt . See http://www-users.cs.umn.edu/~jjeong/publications/international-conference/vtc2004-spring-jaehoon.pdf as well. I like that proposal a lot, but we must be clear on the use case. We discussed that some time ago on the list as well, but I could not dig out the link.

The potential issue I see for both approaches is due to the "proxy" states in the network (and this is why RRH uses source routing as opposed to transparent):

2a) If the nested structure moves as a whole, it's neat. If it's all swarming then the proxy states are all wrong all the time and the packets do not make it through. So the issue is the resilience to movement. It seems that when the tree grows deeper, or when the inner or in/out movement get more and more important, the chances to reach a node drop rapidly.

> >
> > > It seems preferable, for instance, to establish a MR-CR tunnel and exchange fine grained
> routes for MNPs over the tunnel (route projection).
> >
> > I think I agree on this.
> 
> 	This is, IMHO, a different approach, in which the RO requires some
> support from the routing infrastructure, and that present some
> advantages. But, OTOH, solutions based on MR-CN RO are also interesting
> IMHO, as an approach that does not require support in the routing
> infrastructure and puts the RO support functionality only in the edges,
> i.e. the CN and the MR (if the transparency to the MNNs is required, the
> MR is the other edge in which RO mechanisms can be added).
> 
> 	What do you think?
> 

Right. It would be very nice if you can keep the ML aware of your progress. This solution seems very representative of the MR-CN solution space.

Simulating and testing should demonstrate the expected benefits of the approach, but also show what the limits are in terms of performance in the MR, scalability in the mobile cloud, and resilience to  the relative movements within the nested NEMO.

Note that RRH allows MNN-CN RO, but it's not documented too much and the solution is not finalized at all; but as opposed to your requirements, it would require a change to the MNN and the CN to get there. The idea is that the MNN would insert an RRH with all slots blank.

Pascal

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 20 Oct 2004 13:36:32 +0200

Hi Pascal,

First, thank you very much for the feedback and comments, we really
appreciate so much them. Please, see the comments in-line,

> Is the MIRON document already published in a final form or does it make sense to provide feed back for lower interest things like typos? For the time being, let me discuss concepts.

It is already published, so I'm afraid the typos cannot be fixed :-(

> 	If the MNN is a visitor that handles its own mobility and RO, the MR might in fact act as an attacker (against its will :). CoT messages might clash, and if the MN moves away, the MR might keep th…

This part of the solution ("proxying") is only intended to LFNs, as it's
stated on the document.

> 	For instance, CN is a VPN entry point for MNN, and MNN handles its own IPSEC. Manipulating packets on the fly will cause them to be dropped.

Agree. We are aware of that. Maybe it is not clearly stated in the doc,
but of course if end-to-end IPSec is used, this part of the solution
cannot be applied.

> 	MR has to snoop packets to the MNN in order to find CoT. This defeats the very purpose of the test (collocation). So if the test is improved in some future, it might not work anymore. And it's pre…

I agree that if RR is changed in the future, our solution may not work.
Nevertheless, we proposed this, as you call "dirty" solution, just
because we didn't want to change RR (one of our main goals is to propose
a solution that does not require changes to deployed protocols and
nodes, i.e. MIPv6 MNs and CNs).
I agree that reading someone else's packets is not the ideal solution,
but OTOH, if you don't want your packets to be read, you use IPSEC.
Besides, if you don't use IPSEC, your router (or someone in the path)
can read your packets anyway.

> In short, it is going to be software routed for quite some time.

Well, as some other solutions proposed so far, this solution is not
intended to be used with _every_packet routed by the MR. There are many
flows that are not worth to be "MIRON-processed" ;-) (e.g. DNS, etc).
Some heuristics have to be defined to make the decision about which
"LFN-CN" flows should be optimised and which not.

> 2a) If the nested structure moves as a whole, it's neat. If it's all swarming then the proxy states are all wrong all the time and the packets do not make it through. So the issue is the resilience…

Well, we are simulating now our solution in order to check this an other
issues we have detected so far. OTOH, IMHO that is not such a big
problem, if a nested tree moves, root-MR detects the movement, and the
it can inform the other MR using DHCPv6 (DHCPv6 supports sending
information from the server to clients). The new addresses would be
propagated to the MRs within the nested tree and then every MR would be
able to send the appropriate BU.

> Right. It would be very nice if you can keep the ML aware of your progress. This solution seems very representative of the MR-CN solution space.

Actually, we were thinking in submitting a revised version of MIRON to
the WG formatted as an I-D to further discussion, but we were waiting to
have some more simulation results and we were also waiting to the
possible recharter of the WG to focus on RO solutions.

> Simulating and testing should demonstrate the expected benefits of the approach, but also show what the limits are in terms of performance in the MR, scalability in the mobile cloud, and resilience…

Agree. Actually, we are now working on that.

> Note that RRH allows MNN-CN RO, but it's not documented too much and the solution is not finalized at all; but as opposed to your requirements, it would require a change to the MNN and the CN to ge…

That's also interesting. The problem, IMHO, is that it would break the
CN and MNN transparency.

-- 
Carlos Jesús Bernardos Cano - http://www.it.uc3m.es/cjbc/
GPG FP: 58C3 4227 AF8D 01D4 5A09  A617 E6F2 B23E DAD6 AA40

---

From: Masafumi Watari <[email-masked]>
Date: Thu, 21 Oct 2004 01:17:33 +0900 (JST)

Hi Carlos and Pascal,

I find MIRON interesting since I had previously worked on something
very similar, what I called, "Binding Proxy Agent (BPA)" to provide RO
between MIP6 MN and standard IPv6 CN.  Unfortunatelly all my papers
are in Japanese so I don't have any refs, but I have presented this at
Connectathon2003, and below is the pdf.  (BPA is mentioned later)
http://www.connectathon.org/talks03/cthon-keio.pdf

I also have an evaluation based on the implementation I made as an
extention to KAME stack.

BTW, does MIRON work if the CN initializes the RR, and not the MR?
Also, it seems very costly to perform RR for every packet destined to
the LFN, no?

Some more comments inline;

On Tue, 19 Oct 2004 18:57:03 +0200,

> 	If the MNN is a visitor that handles its own mobility and RO, the MR might in fact act as an attacker (against its will :). CoT messages might clash, and if the MN moves away, the MR might keep th…

This can be checked by sending MIP6 like packet to the MNN from the MR
and see its response, or if the VMN moved from a different link, it
would send a BU to its HA which would be an indication of it being a
VMN.  MR should keep a list of those VMN though.

> 	For instance, CN is a VPN entry point for MNN, and MNN handles its own IPSEC. Manipulating packets on the fly will cause them to be dropped.

This is true.

> 	MR has to snoop packets to the MNN in order to find CoT. This defeats the very purpose of the test (collocation). So if the test is improved in some future, it might not work anymore. And it's pre…

Yes, it is dirty, and I did something similar for BPA.  But since BPA
focused on assisting the deployment of MIP6, I thought it be a trade
off.  For MIRON, since it targets NEMO, I would prefere something like
a CR place near CN and not modify the packet.

> 	Too bad MIP RO to CN is based on Home addr option as opposed to tunnels, which does not seem to be an option. The MR has to match source AND destination in order to find whether it can do RO to th…

Why do you compare it with the tunneling cost?

watari

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 20 Oct 2004 20:17:51 +0200

Hi Masafumi, and Pascal,

	Thanks for your reply. Comments inline...

> http://www.connectathon.org/talks03/cthon-keio.pdf

	It seems similar in the sense that is a kind of proxy. But in your
case, if I've understood well, you tried to provide some RO between MNs
and normal IPv6 nodes (without MIPv6 RO CN capabilities). In our case,
we try to provide some MIPv6 RO between MIPv6 CNs and LFNs inside the
MN.
	/* NEMO Off Topic: I find your proposal very interesting, but difficult
to deploy, because you need to have BPAs near the CNs */

> BTW, does MIRON work if the CN initializes the RR, and not the MR?

	Yes, you refer to a CN that's actually a MN, don't you? In that case, I
think that MIRON will also work, if the LFN has the MIPv6 CN
capabilities.

> Also, it seems very costly to perform RR for every packet destined to

	Well, it depends of how many different "LFN-CN flows" the MR tries to
optimise. Moreover, not all the "flows" should be optimised (some
heuristics should be added to decide which flows are worth to be
optimised).

> VMN.  MR should keep a list of those VMN though.

	I think that are other ways to know whether a MNN is a LFN or not. But,
anyway, some list should be kept by the MR (at least, the list of
"LFN-CN flows" being optimised).

> a CR place near CN and not modify the packet.

	As Pascal has pointed out (I agree with him), IMHO, it depends on the
scenarios. Different scenarios may impose different requirements. For
example, IMHO, in not all the scenarios may be feasible to place a CR
near a CN...