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

[Carlos Jesús Bernardos Cano <[e-mail]>]

Hi Pascal,

El mié, 20-10-2004 a las 16:35, Pascal Thubert (pthubert) escribió: 
> , 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
> > 
> > This part of the solution ("proxying") is only intended to LFNs, as it's
> > stated on the document.
> This is part of the typo part then, the MNN acronym is used sometimes. The
> Next question is whether you have to prevent VMNs or if you add an algorithm to detect those clients for which you do not do RO. Snooping?

We have to detect those clients that are not LFNs, and just do not
consider them as candidates for MIRON. It's IMHO easy, and can be done
by looking at the headers of the packet.

>  
> > > 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.
> > 
> > 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.
> 
> Again this require more snooping. Anyway, we found nothing better in the exploration of solutions that would be transparent to CN and MNN. All this snooping seems to be the price to pay for the requirements you took. Note that global HAHA approaches from the other end of the spectrum. RO is between proxies that belong to the infrastructure and exchange projected routes over dynamic tunnel (route projection). Protecting the privacy the CoA from the other end is another requirement that appears sometimes. 
> 
> There might be different sets of requirements and the requirements end up orienting the solution quite dramatically. I'm not even sure that the WG will be able to sort out THE set of requirements with THE order of priority so that we can devise THE RO solution. It might appear that the best fit RO solution depends on the type of deployment. We'll see :)

Yes, I agree. MIRON is just a proposal that provides some RO, without
requiring any change on the CN/MNN operation. When we started to address
the RO issue in NEMO, one of the strong requirements we had in mind was
exactly that: to not change the CN/MNN operation. Of course, MIRON does
not try to be THE solution, just one initial approach that may be useful
in some cases and that may be also helpful to us in the understanding of
the NEMO RO problem.

> > 
> > > 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 :) ?
> > 
> > 
> > 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.
> > 
> > > 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.
> > 
> > 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.
> Sure, that makes sense to me. The point is still that you have to look up every packet and match both source and destination to see if you have a proxy binding. This is 1) quite costly in terms of CPU and 2) I'm afraid that hardware acceleration will not be easy to perform, as opposed to simple tunnels; same for inserting headers inside the packet. 

Well, routers have to look in the headers of every packet anyway,
haven't they?
It is heavier in terms of CPU that just using a tunnel, but IMHO, there
are many protocols/services/applications today that already require
software processing (e.g. firewalls, etc), and BTW, we are trying to do
some optimising, so isn't that worth adding some CPU load in the MR? ;-)

> > > 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.
> > 
> > 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.
> > 
> I do not mean it's that bas when the tree moves as a whole; but rather when each node is independent and moves relatively to other nodes. Think of MRs in car, wireless APs on the traffic lights and some buildings. And imagine that to get to the AP, you might needs to hop over one or two cars, because you are in a shadow area around the block or something.

I'm not sure to get your point. I'm not sure if you are thinking in a
MANET scenario, in which ad-routing protocols take care of the problem.
If you are thinking in a non-MANET scenario, I don't see the problem
either. I don't see clearly why you say that with MIRON, in the scenario
you point out, the chances to reach a node drop rapidly. With MIRON,
when a MR moves, if it is the root-MR, it just has to obtain IPv6
addresses using DHCPv6 (to be used by itself, and by every nested MR
below it), and update the binding with its HA, using standard NEMO Basic
Support protocol. If the MR is not a root-MR, it just receives an update
of the IPv6 addresses used by itself and the MRs it has below, and
updates the binding with its HA.

> 
> > >
> > > > >
> > > > > > 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.
> > 
> > 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.
> 
> Cool, please keep us tuned on the simulation results :)
> 
> > 
> > > 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.
> > 
> > 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 get there. The idea is that the MNN would insert an RRH with all slots blank.
> > 
> > That's also interesting. The problem, IMHO, is that it would break the
> > CN and MNN transparency.
> > 
> You're right. I'm pointing out that there is a world of solutions depending on what the key reqs are...

Completely agree.

Carlos

> Pascal

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