Subject: [nemo] review of draft-ietf-nemo-ro-space-analysis-00

From: Jari Arkko <[email-masked]>
Date: Fri, 09 Sep 2005 16:44:52 +0300

I've read this draft. Very nice document, and a good
view to the solution space. In fact, I got a bit scared
after having read this document, given the various
issues with deep nesting, signaling storms, security,
and the very different solutions that have been
proposed.

Some comments:

>    o  Avoid the Security Policy Issue
>
>       Security policy may forbid Mobile Routers from tunneling traffic
>       of Visiting Mobile Nodes into the home network of Mobile Router.
>       Route Optimization can be used to avoid this issue by forwarding
>       traffic from Visiting Mobile Nodes directly to their destination
>       without going through the home network of the Mobile Router.
>
>    o  Avoid the Instability and Deadlock
>
>       [1] described a potential deadlock situation when a Home Agent is
>       nested within a Mobile Network.  Route Optimization may circumvent
>       such deadlock situations by directly forwarding traffic upstream.

As discussed on the list earlier, I believe the above presents
a slightly too simplistic view. In the second item its possible
that some RO signaling needs to go via the home network anyway,
which wouldn't be able to run if there was really a loop.

In the first item we need to realize that there are multiple
different types of security policies. One type in conflict
with the above is the "route all traffic to the inspection
point at home" -policy. Another issue is that a MR that
simply lets all traffic flow from its own attachment point
would still be subject to be held responsible for
illegal traffic & attacks from its MNNs. Where this is
an issue, the solution may exist in some other layers
than in NEMO, such as in network access control
mechanisms.

(Also, is there a need to talk about a similar form of "route
optimization" that is already present in Mobile IPv6
with hosts deciding to use care-of address for some
of their short-lived communications? If the hosts behind
the MR actually were able to learn their true "care of
addresses", this might be possible -- with impacts to
these hosts and prefix discovery, of course.)

>    We start off with a scenario where nesting of Mobile Routers is not
>    considered, and Route Optimization is initiated and performed between
>    a Mobile Router and its peer Mobile Router, also known as a
>    Correspondent Router.

This solution appears to have very limited applicability,
given that it requires nemo devices on both ends,
likely reducing deployment to only conversations
between two mobile networks.

>   Since Mobile IPv6 defines its own
>   Route Optimization mechanism, providing optimal path for such hosts
>   will require interaction with the protocol and may require an
>   altering of the messages exchanged during the Return Routability
>   procedure with the Correspondent Node.

This sounds interesting. I realize there are complexity
issues, but it would be preferrable to have a single RO
mechanism for CNs rather than two. Extensions
to base mechanism would be needed, of course,
and I have not looked at how hard that is.

>    One advantage of NEMO Basic Support is that the Correspondent Nodes
>    and Mobile Network Nodes need not be aware of the actual location and
>    mobility of the mobile network.  With Route Optimization, it might be
>    necessary to reveal the point of attachment of the Mobile Router to
>    other nodes, such as the Mobile Network Nodes or their Correspondent
>    Nodes.  This may mean a tradeoff between location privacy [16] (and
>    mobility transparency) and Route Optimization.
>
>    In Mobile IPv6, a mobile node can decide whether or not to perform
>    Route Optimization with a given Correspondent Node.  Thus, the mobile
>    node is in control of whether to trade location privacy for an
>    optimized route.  In NEMO Route Optimization, if the decision to
>    perform Router Optimization is made by the Mobile Router, it will be
>    difficult for Mobile Network Nodes to control the decision of having
>    this tradeoff.

This seems problematic. I'd like the MNNs to be in control of this
(if they want to; some MNNs are probably unmodified IP hosts).

> 4.8  Security Consideration

The text in this section is good, but it seems to miss an
important part which is explaining the difference between
host themselves performing RO vs routers performing it for
them. It appears to be a harder problem in terms of, say,
seeing inside the tunneled packets, proving ownership of
the addresses or sessions, etc.

>    All these concerns over the authenticity of addresses might suggest
>    that perhaps a more radical and robust approach is necessary.  This
>    is currently under extensive study in various Working Groups of the
>    IETF, and many related documents might be of interest here, such as
>    Securing Neighbor Discovery (SEND) [28], the use of Cryptographically
>    Generated Addresses (CGA) [29], various enhancements to the Route
>    Optimization scheme of Mobile IPv6 [30][31], and possibly Host
>    Identity Protocol (HIP) [32] with end-host mobility considerations
>    [33].

You may wish to take a look also at the paper by Jukka Ylitalo
in NDSS'05 workshop. This is based on a delegation approach,
where MNNs delegate some rights to MRs, they in turn may
delegate them further etc.

Also, presumably you could use techniques such as those in
[31] to allow a secure communication between a home agent
and correspondent nodes, and use this to tell the CN that
a specific MR exists at a specific location for the prefix. The
good thing with this approach is that its aggregatable
for all hosts within the prefix, i.e., you need to tell the CN
only once.

>    Although a standardized NEMO Route
>    Optimization solution has yet to materialize, one can expect it to
>    show some of the following benefits:

> (a set of benefits snipped, then later some disadvantages are listed:)

>    This may lead to an issue that impacts NEMO Route Optimization, known
>    as the phenomenon of "Binding Update Storm", or more generally,
>    "Signaling Storm".  This occurs when a change in point of attachment
>    of the mobile network is accompanied with a sudden burst of signaling
>    messages, resulting in temporary congestion, packet delays or even
>    packet loss.  This effect will be especially significant for wireless
>    environment where bandwidth is relatively limited.

Obviously the choice of the mechanism affects this (e.g. MR doing this
vs. MNNs doing it). But I'm worried that this may still not be enough,
because even MR-based mechanisms have to deal with a large number
of different endpoints; potentially multiple flows from each MNN to
all different CNs.

This would seem to imply that there has to be some adaptive
behavior that depends on the number of signaling connections
that would have to be updated vs. the effort needed to tunnel
home.

Another architectural issue is the amount of state needed in
the MRs. Traditionally, we've tried to avoid additional state
per pair of peers in the routers.

--Jari

---

From: Masafumi Watari <[email-masked]>
Date: Mon, 12 Sep 2005 19:09:21 +0900

Hi,

Thanks for your review.  Please find my comments inline;

> which wouldn't be able to run if there was really a loop.

Right.  I think the assumption here was that such RO mechanism
would allow the MR to find its HA somewhere in the nest,
avoiding the loop problem.

> than in NEMO, such as in network access control

Well, if the MR forwards all packets from a VMN to the HA of that VMN,
it wouldn't threanten its home and would simple work as any transit
router.  Illegal traffic from the MNNs would eventually look as if they
were originated from their home network, thus MR should not be held
reposible for that.  Such path would involve atleast one of the HAs,
however the path should still be effective in some cases.  This is just
an example.  OTOH, the MR would be held reponsible for attacks to its
MNNs, but I don't think that NEMO is a solution for that either.

But I agree that this contradicts the problem of not having
RO singaling messages to travel home.

> these hosts and prefix discovery, of course.)

I couldn't catch what the issue is with this one.

> between two mobile networks.

This is perhaps the most simple case, i.e. does not involve nesting
so it may sound limited.  But, if you consider moving vehicles, they
would each have nemo devices provindg optimal path for all its MNNs, so
there are some reasonable applicabilities.

> and I have not looked at how hard that is.

The most simple case is to have the CN establish bindings for both MR
and its VMN, and have it do a recursive binding lookup.  But there are
a lot of issues with it, such as authorizing the prefix ownership of the
MR, tunnel overhead, singaling and such...

watari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 12 Sep 2005 14:50:16 +0300

Masafumi Watari wrote:

> it wouldn't threanten its home and would simple work as any transit router

Right, although this is not the only possible solution. The other
solution is network access control, where someone in the access
network who is who and can send in the police to the right person.

> Illegal traffic from the MNNs would eventually look as if they

Right, it shouldn't be.

> RO singaling messages to travel home.

Yes.

> I couldn't catch what the issue is with this one.

I meant the possibility that a MNN would learn its true
local care-of address, and be able to use either that
or the more stable address provided by NEMO.

> there are some reasonable applicabilities.

Perhaps. But the work ahead of us seems pretty big, so this would
be an excellent time to think what our priorities are and what
problems are most useful ones to solve. That's part of the
problem definition phase, not just listing what problems that
could be solved, but also what ones we really want to solve.

--Jari

---

From: Masafumi Watari <[email-masked]>
Date: Tue, 13 Sep 2005 18:20:50 +0900

On 2005/09/12 20:50, Jari Arkko wrote:
>> router

Right.

> or the more stable address provided by NEMO.

Ok and I agree, we should mention that somewhere in Section 5.

> could be solved, but also what ones we really want to solve.

Right.  So I guess this goes back to your comment on the problem
statement draft about seeking interests of the service providers wishing
to deploy NEMO (and MIP6 because the two could interact in some
scenarios).  We also had a similar discussion during the last meeting on
such priorities and I believe this is also concerned with the WG
rechartering.

watari

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 14 Sep 2005 10:36:51 +0200

> such priorities and I believe this is also concerned with the WG

I agree that given the priorities and that the work ahead seems pretty
big, probably yhe first issue to tackle is the use of CoA for app-level
communications within the nested moving network (when the HAs are not
available).

Alex