Subject: [nemo] RO taxonomy

From: Erik Nordmark <[email-masked]>
Date: Fri, 22 Oct 2004 14:23:45 -0700

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.

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.

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?

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 :-)

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.

    Erik

---

From: Chan-Wah NG <[email-masked]>
Date: Sat, 23 Oct 2004 10:06:15 +0800

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

> 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)?

> is pointing out a feature and not a bug.
OK.

> 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.

> draft-nordmark-mobileip-mipv6-hindsight-00.txt :-)
Ok.

> 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: Sun, 24 Oct 2004 21:59:02 -0700

> I have read, I will try to include your text into the drat if you don't

Fine with me.

> impact if IPSec is also used (eg. AH)?

Maybe, but that has nothing to do with whether RR or something else is 
used for securing the signaling.

If AH is used, then presumably the presence of the destination options 
header with the HAO is also part of the integrity check.
So it would be symmetric that a proxy needs work when AH is in use???

The proxy could advance the RH2 instead of removing it, which would make 
the destination happy and AH would verify correctly.
But that doesn't handle the need to insert the HAO for packets in the 
reverse direction; I guess a proxy could be built so that a packet from 
a LMN which has AH after the IP header will be reverse tunneled instead
of having the HAO added.

> invaluable and appreciated.

I'll have a look.

   Erik