Subject: [nemo] More comments on the RO problem statement draft

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 29 Aug 2005 17:25:12 +0200

I've just went through the draft, thanks for putting it up in a concise
form.

First, I'll repeat along the lines of the recent Jari posting about
vendors/deployment necessity.  Having an RO problem statement is good,
at least to acknowledge the protocol issues with moving networks.  To
that end I see necessity of the Problem Statement draft.  However,
developping an RO scheme for NEMO should be subject to deployment needs
and user experience first.

Section 2.5 "Security Policy Prohibiting Traffic From Visiting Nodes"
poses problems for my understanding.  The title is expressive, however
the description is difficult to grasp, IMHO.

> it can be expected that in many deployments, policies will be put in 
> place to prevent untrusted visitors from attaching to the Mobile 
> Router. [...] A Route Optimization mechanism that would prevent the 
> multiple re- encapsulation of the packets by nested Mobile Routers 
> might as a side effect alleviate this limitation

In my understanding "policy" is like packet filters on MR, that would
simply block anybody else than the known LFNs to connect to that moving
network.  No RO mechanism could do anything against those policies.  If
they're in place then nothing could be done about them.

Maybe the moving networks problem was this: any moving network can
attach to another moving network and there may be DoS attacks when
entities administrated by different separate administrative domains take
networking ressources from each other without a formal agreement.  In
that case a formal agreement may solve the problem, but not an RO
solution which is mainly designed to shorten paths.  No?

Section 2.7 "Deadlock with a Home Agent Nested in a Mobile Network" has
a textual illustration (ASCII art) of a mobility configuration
experimented in lab and where MRs can't update their HAs because the
tunnels would "cross-over" each other if they were set, instead of
"encapsulating" each other (see section B.6 in an expired draft at
http://tinyurl.com/4z4kc).

Section 5 "Security Considerations" - ok this document does not
introduce any security issues, but what about the potential extensions
of the (security) RR mechanisms that can't be logically extended to
return routability tests for entire prefixes (the MNP instead of HoA)?
This was one of the important issues of not looking at RO mechanisms for
NEMO, because it was said that extending RR to support prefixes is very
unclear.

Alex

---

From: Masafumi Watari <[email-masked]>
Date: Wed, 31 Aug 2005 13:37:24 +0900

Hi,

> solution which is mainly designed to shorten paths.  No?

RO solution is designed to shorten paths, which means that it's
providing an alternative paths for the MNNs.  Since the alternative
path is different from the default MRHA tunnel, the MRs may decide
to forward packets for the vistor through the alternative path since
the path will not threaten its home network.

We didn't define what the "policy" might be, but if the policy prohibits
a vistor to connect to its mobile network, as you mentioned, then I
a RO solution is not designed to solve that problem.

> NEMO, because it was said that extending RR to support prefixes is very

The document is not intend to discuss any potential solutions, but
perhaps in the Solution Space Analysis draft which is to be published
soon.

watari

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 31 Aug 2005 14:04:33 +0200

Hi Watari,

Masafumi Watari wrote:

>> I've just went through the draft, thanks for putting it up in a
>> concise form.
>> 
>>  vendors/deployment necessity.  Having an RO problem statement is
>> good, at least to acknowledge the protocol issues with moving
>> networks.  To that end I see necessity of the Problem Statement
>> draft.  However, developping an RO scheme for NEMO should be
>> subject to deployment needs and user experience first.
>> 
>> Section 2.5 "Security Policy Prohibiting Traffic From Visiting
>> Nodes" poses problems for my understanding.  The title is
>> expressive, however the description is difficult to grasp, IMHO.
>> 
>>> it can be expected that in many deployments, policies will be put
>>> in place to prevent untrusted visitors from attaching to the
>>> Mobile Router. [...] A Route Optimization mechanism that would
>>> prevent the multiple re- encapsulation of the packets by nested
>>> Mobile Routers might as a side effect alleviate this limitation
>> 
>> 
>> In my understanding "policy" is like packet filters on MR, that
>> would simply block anybody else than the known LFNs to connect to
>> that moving network.  No RO mechanism could do anything against
>> those policies.  If they're in place then nothing could be done
>> about them.
> 
>> 
> 
>> entities administrated by different separate administrative domains
>> take networking ressources from each other without a formal
>> agreement.  In that case a formal agreement may solve the problem,
>> but not an RO solution which is mainly designed to shorten paths.
>> No?
> 
> 
> path is different from the default MRHA tunnel, the MRs may decide to
> forward packets for the vistor through the alternative path since the
> path will not threaten its home network.
> 
> We didn't define what the "policy" might be, but if the policy
> prohibits a vistor to connect to its mobile network, as you
> mentioned, then I a RO solution is not designed to solve that
> problem.

Thanks.  I've re-read the section.  It says that with typical networks,
maybe T4T is used and nodes do connect to each other without worry.  And
it says that with NEMO if VMNs are allowed to connect to moving networks
then the T4T "policy" may no longer apply because traffic goes through
HA, which is another network.  And which may make administrators to no
longer apply T4T.  But if NEMO used RO then the administrators would
continue to indulge VMNs, because traffic would no longer go through HA.

The reasoning sounds complicated to me, it makes assumptions on too many
unknown things (T4T, policies, etc).

Maybe it would be easier to say something along the lines of this: if
NEMO uses RO then there is more probability that moving networks will be
allowed (policy-wise) to connect to each other.  Does this follow?

>> Section 2.7 "Deadlock with a Home Agent Nested in a Mobile Network"
>> has a textual illustration (ASCII art) of a mobility configuration 
>> experimented in lab and where MRs can't update their HAs because
>> the tunnels would "cross-over" each other if they were set, instead
>> of "encapsulating" each other (see section B.6 in an expired draft
>> at http://tinyurl.com/4z4kc).
>> 
>> introduce any security issues, but what about the potential
>> extensions of the (security) RR mechanisms that can't be logically
>> extended to return routability tests for entire prefixes (the MNP
>> instead of HoA)? This was one of the important issues of not
>> looking at RO mechanisms for NEMO, because it was said that
>> extending RR to support prefixes is very unclear.
> 
> 

I agree this document should not have discussion of potential solutions.
 I just wanted to mention that there is a "prefix ownership problem"
just like there is an "address ownership problem" (which was addressed
with CGA).  It is little feasible to use CGA to address the "prefix
ownership problem".  It is little feasible to do return routability
testing for all addresses comprised by a prefix.  Without addressing the
"prefix ownership problem" it little feasible IMHO to have RR/RO like
MIP6 is.

Maybe it's not correctly formulated...

Maybe something should be said like this: assume RO is needed for NEMO.
 It is then needed to use mechanism similar to MIP6 RR.  But MIP6 RR is
used to ensure that a certain address is owned by a MN.  It can't be
extended to ensure that an entire prefix is owned by an MR.

"Prefix Ownership": when MR tries to instruct a CN that its MNP is at a
new CoA it should have a means to convince CN that that particular MNP
is actually the MNP that the MR is administratively assigned, in order
to avoid security attacks.

Maybe still not correctly formulated, but you may get the idea...

Alex

---

From: Fan Zhao <[email-masked]>
Date: Wed, 31 Aug 2005 15:32:52 -0700 (PDT)

Dear Alex,

Prefix ownership is addressed in the solution space analysis draft.
And I have a draft, draft-zhao-mip6-rr-ext-01, which provides an
alternative way to guarantee the validity of prefix without
generating many test messages.

Sincerely,
fan