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

From: Chan-Wah NG <[email-masked]>
Date: Thu, 01 Sep 2005 13:38:29 +0800

Hello Alex, all,

On Wed, 2005-08-31 at 14:04 +0200, Alexandru Petrescu wrote: 
> Hi Watari,
> 
> Masafumi Watari wrote:
> 
> > Hi,
> > 
> > On 2005/08/30 0:25, Alexandru Petrescu wrote:
> > 
> >> 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?
> > 
> > 
> > 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.
> 
> 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 actual problem is actually security policy forbiding VMN.  The T4T
is just an example to illustrate the scenario where you would want to
allow VMN.

Personally, from comments gathered from people who'd read the draft
during Paris meeting, I think the T4T example is clouding people from
the real problem.  I am inclined to re-arrange the text in that section.

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

Perhaps, but it does not sounds like a "problem" to me, more of a
motivation.  I would've preferred a change of point of view to start off
with problem of NEMO-Basic leading to why RO is needed.

It's all a matter of wording.

> >> 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.
> > 
> > 
> > The document is not intend to discuss any potential solutions, but 
> > perhaps in the Solution Space Analysis draft which is to be published
> >  soon.
> 
> 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...
> 

As mentioned, please see the RO-Space-Analysis draft, which is already
in the I-D Secretariat's queue.  We have devoted quite a few paragraphs
on this.

/rgds
/cwng

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 01 Sep 2005 10:58:17 +0200

> with problem of NEMO-Basic leading to why RO is needed.

Agree, it does not sound like a "problem" to me either.  So if there is
no way to meaningfully formulate it as a problem (I'm not excluding the
possibility for someone to formulate it as a problem) then maybe it does
not fit in the problem statement doc.

> in the I-D Secretariat's queue.  We have devoted quite a few paragraphs

Ok, sorry for pushing.

Alex

---

From: Jari Arkko <[email-masked]>
Date: Wed, 07 Sep 2005 14:10:43 +0300

>allowed (policy-wise) to connect to each other.  Does this follow?
Not necessarily. Firstly, there might be networks
that want to have all traffic inspected to begin with,
even with their own nodes. Secondly, you would
need an RO solution that does not need the home network
at all, as otherwise this does not alleviate the home
network admin's fear that bad packets will be routed
to it. Finally, you would assume that someone who
deploys nemo routers designs their network in
a manner that matches the desired user population,
e.g. own users -> their internal network, any users ->
only the external network.

But I do agree that it sounds somewhat dangerous
to let in anyone and route the traffic through your
home network, even if its only the external side. Any
spam/illegal content etc. problems would first be
blamed on you, not the unauthenticated users.

There's also the question of whether its NEMO or
something else that solves this problem. Presumably
if you worry about this then you could also require
network access authentication.

--Jari