Subject: RE: [nemo] RO taxonomy

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Mon, 25 Oct 2004 09:40:46 +0200

Chan-Wah, Erik:

What I meant here is that the RR test and the RH2 support are meant to check and use the collocation of the HoA and the CoA in a same box. The best the test operates, the less chances this proxying has to work. If the test was perfect, it would not. 

What Erik describes here is very close (if not identical) to the MIRON project (copying Carlos). There's a good chance it works in many cases, at least with the current RR test. I do not want to start again all the discussion we had on this ML. The thread was "RO between MR and CN", and I listed my concerns on the 10th of October.

In short, I believe that the devil is in the details. I like the wording "packet inspection" ;) , but the words snooping and hacking apply very well too. I see it falling short after some time. The MR will end up having to lookup every packets for source and destination, and modify all the RO'ed packets. Also, it has to sort out whether the MNN is managing its own mobility or security, or if there's another MR or RO solution of some sorts that would defeat its action.

I'm not too positive on the approach. I think that at least we should allow normal tunnelling between MR and CN to get there, and I agree with CW that we should revisit the RR test. RR is a Work In Progress anyway. So I'm not necessarily for keeping the CN unchanged whatever the cost.

ITOH, there are alternatives to the end-to-end RO. For instance, global HAHA proposes a 'pth improvement" between fixed proxies, distributed in the Internet, as an alternate to RO. No Home address or RH2, but route projections and tunnels. This also protects the MNN and the CN. In fact, they both are plain non MIP nodes. You might want to have a glance at:
http://www.ietf.org/internet-drafts/draft-thubert-nemo-global-haha-00.txt
 
Note that this is only a draft 00 and there's still a lot of work to do. 

Pascal

> -----Original Message-----
> From: Chan-Wah NG [mailto:[email-masked]]
> Sent: samedi 23 octobre 2004 04:06
> To: Erik Nordmark
> Cc: Pascal Thubert (pthubert); IETF NEMO WG
> Subject: Re: [nemo] RO taxonomy
> 
> Hello Erik,
> 
> Thank you for the comments, as we currently updating the draft (almost a
> complete re-structuring), and your comments are very useful.
> 
> More responses below inline.
> 
> /rgds
> /cwng
> 
> On Sat, 2004-10-23 at 05:23, Erik Nordmark wrote:
> > Thanks for writing the RO taxonomy draft - it introduces some issues
> > which makes it easier to discuss them without diving into the solutions.
> >
> > I have a couple of high-level comments and concerns.
> >
> > The draft concludes, without any motivation, that the RR test prevents
> > having a MR "proxy" mobility signalling for a LFN.
> > I don't see why this would be the case. To perform such proxying one
> > needs know that there is at most on MR being the proxy i.e. can't have
> > two MRs serve the mobile network with some packets to/from the LFN
> > passing through one and some through the other. And then the MR needs to
> >   - determine when to perform RO (e.g. by counting packets in the flows)
> >   - send CoTI and HoTI on behalf of the LFN
> >   - receive the CoT (which is trivial since it is address to the MR)
> >   - receive the HoT (which requires packet inspection of the
> >     packets addressed to the LFN)
> >   - send the BU and receive the BA
> >   - insert the HAO in packets from the LFN
> >   - remove the RH type 2 in packets to the LFN
> >   - adjust ICMP packet too big to account for the inserts and removes it
> >     performs
> > 	- both the MTU and the "packet in error" needs to be adjusted
> >
> > I can see how such a proxy can be built, and I don't see it being much
> > harder with RR then with other forms of security like CGA or
> > infrastructure based ones.
> >
> 
> Okay, that's thus far the most detailed description of a "RO-proxy" that
> I have read, I will try to include your text into the drat if you don't
> mind?
> 
> However, off-hand, one concern for this is security-related.  The
> modification of data packets (i.e. removing RH2): wouldn't it have
> impact if IPSec is also used (eg. AH)?
> 
> >
> > The draft seems to both assume that it is ok to modify CNs to handle
> > Nemo, and that it is necessary to do such modifications.
> > I think it is possible to do both MR proxy RO (for LFNs) and VMN RO
> > without any modifications to the CNs; they would just do MIPv6 CN as
> > currently defined.
> > Thus the text which says
> >     2) The RR test has no negotiable option and is not open for
> >     extension, and
> > is pointing out a feature and not a bug.
> >
> OK.
> 
> >
> > In section 2, the paragraph
> >     This section covers the case where the Route Optimization is
> >     performed between the MR and the correspondent nodes which mobile
> >     network nodes (MNNs) are communicating with.  This scenario is useful
> >     when a lot of MNNs in a mobile network is communicating with a few
> >     corresponding nodes.  In such cases the MR only needs to send one
> >     binding update (BU) to optimized the route between CN and a few MNNs.
> > seems to imply that a BU to a CN for a prefix is somehow possible.
> >
> > When the CN and mobile network are in different administrations it is
> > extremely unlikely that there would be an infrastructure which would
> > allow the CN to make reasonable authorization decisions for a full prefix.
> > For instance, the current RR scheme could only derive such authorization
> > without loss of security if the RR test is applied to all of the 2^N
> > addresses in the prefix. Similarely for CGA scheme, each individual
> > address would need to be verified.
> > So why are you implicitly assuming that this is feasible and desirable?
> >
> 
> In the upcoming version of the draft, we indeed will point out this
> concern of verification of prefix "ownership".
> 
> Side-tracking a bit, I have written another draft (draft-ng-nemo-rrnp)
> on this. Should you be not too busy, a comment or two from you would be
> invaluable and appreciated.
> 
> > Section 7 says:
> >     3) The HaO and RH type 2 are designed for a collocated CareOf
> >     Address. More specifically, they are not designed to be multi-hop as
> >     RRH is, and not extensible, though RRH can be considered as an
> >     extension of HAO.
> > I think somebody pointed that out in
> > draft-nordmark-mobileip-mipv6-hindsight-00.txt :-)
> >
> Ok.
> 
> >
> > I think there is important consideration which has a large effect on
> > the possible solutions for both VMNs and for nesting; whether or not the
> > AR will delegate a prefix to the MR.
> > If the MR receives a single address from the AR, then this has to be
> > used as a "shared CoA" for all devices in the mobile network which
> > wishes their packets to travel directly to the mobile network.
> > But if the MR receives a prefix from the AR that it delegates to the
> > non-LFN nodes, then each such Nemo aware node can have its own CoA which
> > represents the shortest path via the MR.
> > It might be useful to represent this somehow in the taxonomy.
> >
> Right, with the recent exchanges of mails on prefix delegation, I am
> starting to think that this class of approach may deserve its own
> separate section in the taxonomy.  Previously, it was mentioned as one
> approach in "Nested Network Optimization".
> 
> /rgds
> /cwng

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 25 Oct 2004 09:57:26 -0700

> What I meant here is that the RR test and the RH2 support are meant to check and use the collocation of the HoA and the CoA in a same box. The best the test operates, the less chances this proxying…

I disagree because the IETF doesn't specify the behavior of "boxes" - it 
specifies functional behavior.
Ignoring Nemo, for instance there is nothing that prevents the logical 
notion of a "host" to have its TCP/IP stack in one box (separate power 
supply etc) 10 meters away from the processors where the applications run.

The RR test is fundamentally about authorization, where we assume that 
the host (again, a function and not a box) to which the HoA is assigned 
is authorized to send packets for the HoA somewhere else.

That doesn't mean that it isn't (and shouldn't be) possible for the host 
to delegate the MIPv6 handling to a proxy function, which might be 
running in a different box.

But this is fundamental to the authorization issue; has nothing to do 
with the actual mechanism to show authorization whether RR, CGA, some 
manually per-established keys.

> What Erik describes here is very close (if not identical) to the MIRON project (copying Carlos). There's a good chance it works in many cases, at least with the current RR test. I do not want to st…

I'll go have a peek at MIRON.

> In short, I believe that the devil is in the details. I like the wording "packet inspection" ;) , but the words snooping and hacking apply very well too. I see it falling short after some time. The MR will end up having to lookup every packets for source and destination, and modify all the RO'ed packets. 

I agree that any three-party approach, i.e. anything involving proxies, 
is more complex than a two party approach. But if we want to solve RO 
between a LFN (vanilla IPv6 with no mobility support) and a vanilla 
MIPv6 CN, then it is clear that something in between those two needs to 
do some work i.e. a proxy of some form is necessary.

So the first question is how important it is solve this aspect of the 
problem, and then we can see how to construct the best (but perhaps not 
perfect) proxy solution.

And if you can modify the LFN then you can probably design things to 
avoid a proxy.

> Also, it has to sort out whether the MNN is managing its own mobility or security, or if there's another MR or RO solution of some sorts that would defeat its action.

A MNN wouldn't in general know that there is a MR; it is only for 
Nemo-aware nodes that this question comes up. I think this can be 
handled without interference from the proxy function. The Nemo-aware 
node has two choices in terms of its CoA; it can share the MR's CoA or 
it can get a CoA for itself (from some prefix delegated from the AR to 
the MR and advertised to the Nemo-aware nodes for instance).
If it shares the CoA then the node needs to do some signaling with the 
MR (because the MR would need to know where to forward the packets it 
receives on its CoA and the HoA of the MNN might not be sufficient for 
this in the case of a VMN). Thus, some form of binding update needs to 
be sent from the MNN to the MR. As a result the MR knows not to apply
the proxy function for that HoA.

If the MNN has its own CoA, then the proxy function shouldn't be 
triggered because the packets are from an address space the MR delegated 
from the AR to the mobile network.

> I'm not too positive on the approach. I think that at least we should allow normal tunnelling between MR and CN to get there, 

Of course. What we are talking about is RO which is a performance 
optimization and not a way to accomplish basic connectivity.

 > and I agree with CW that we should revisit the RR test. RR is a Work 
In Progress anyway. So I'm not necessarily for keeping the CN unchanged 
whatever the cost.

I think you are barking up the wrong proverbial tree. Your issue isn't 
with the RR test - it is with the explicit assumption that the "owner" 
of the HoA is the node authorized to say where packets for its HoA are sent.
So replacing the RR test with something that still has at least the same 
strength would never make the fundamental issue you have go away.
One could attempt to build solutions which makes delegating the 
authorization to a 3rd party easier, but that still only solves the 
authorization aspect of the proxy and does nothing about its impact on 
the data path with HAO and RH2.

Note that I'm not saying proxies are easy or a good idea; there is a 
long list of things they need to do correctly and things probably will 
not work when there are multiple paths so that a single proxy do not see 
all packets between a LFN and CN.

What I am saying is that no matter what you replace the RR test with you 
will have the same fundamental issues with proxies.

   Erik