Subject: [nemo] Re: Hierarchical Mobile Router Advertisement

From: Hosik Cho <[email-masked]>
Date: Fri, 27 Feb 2004 19:36:04 +0900

Hi Alex,

Thanks for your detailed comment on my draft.
"Hierarchical mobile router advertisement for nested mobile networks"
http://www.ietf.org/internet-drafts/draft-cho-nemo-hmra-00.txt

Please, read in lines.

> 
> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]] 
> Subject: Re: Hierarchical Mobile Router Advertisement
> 
> Hello Eun Kyoung, thank you for asking me and sorry for not having
> followed-up with this thread when it occured; I continue it now.  Also,
> feel free to continue or re-initiate the discussion on the public list,
> I think it is benefic for the overall advancement.
> 
> Eun Kyoung Paik wrote:
> >>> Internet | AR | Parent MR | Child MR
> >>> 
> >>> In the figure, Parent MR may autoconfigure its CoA after it 
> >>> listens RA of AR. Then, Child MR may autoconfigure its CoA after 
> >>> it listens RA of Parent MR. After that, if Parent MR listens 
> >>> Child MR's RA, Parent MR configures new CoA according to Child 
> >>> MR's RA ?
> >> 
> >> In this particular configuration, I do not think that Parent MR 
> >> configures a CoA based on the Child MR RA.  There are two reasons 
> >> for that.
> >> 
> >> One is that according to the stateless autoconfiguration mechanisms
> >>  a router will not autoconfigure an address on an interface based 
> >> on received RA's.  Parent MR is a router, so.
> > 
> > Then, how MR's egress interface configures its CoA when it moves into
> >  a foreign link ? Doesn't it need RA from foreign link ?
> 
> I agree with you that this behaviour might look questionable.  Let me
> bring back some text from the NEMO base spec:
> 
> > A Mobile Router SHOULD NOT send unsolicited Router Advertisements and
> >  SHOULD NOT reply to Router Solicitations on any egress interface 
> > when that interface is attached to a visited link.
> 
> So, applying it to your scenario, it would mean that the child MR would
> not send RA's on its egress interface (directly connected to the parent
> MR's ingress).
> 

Basically, I assume that a MR has two interfaces. The child MR would not 
send RA's on its egress interface but would send RA's on its ingress 
interface.

> > A router typically ignores router advertisements sent by other 
> > routers on a link.  However, a Mobile Router MUST NOT ignore Router 
> > Advertisements received on the egress interface.  The received Router
> >  Advertisements MAY be used for address configuration, default router
> >  selection or movement detection.
> 
> This, applied to your scenario, would mean that the parent MR's egress
> interface does obtain a CoA from the AR and that the child MR's egress
> interface obtains a CoA from the parent MR's ingress interface's RA.
> 

Right. I think that nested mobile networks are formed this way.

> >> The other is that Child MR is, in fact, visiting the network of 
> >> Parent MR; when a MR is visiting, it acts as a host on its egress 
> >> interface, not as a router.  Thus it will not send RA's on its 
> >> egress interface if it is not at home, so Parent MR does not get 
> >> RA's from Child MR.
> > 
> > I wonder if parent MR's egress interrface listen the RA of child MR's
> >  ingress interface. (Child MR's ingress interface may broadcast its 
> > RA for its VMNs.)
> 
> Right, this is a good question.  I also think that in a nested mobile
> networks configuration where all interfaces are wireless there is a
> danger that some parent MR's egress interface might receive RA's emitted
> by some child MR's ingress interface and might get confused and
> configure a CoA and a default route that do not actually point to the
> Internet.
> 

My draft is focused on that situation when an MR uses both wireless 
interfaces for ingress and egress interface.

> It is entirely true that in such a completely wireless nested
> aggregation there might be a problem with RA's.  And not only RA's, this
> is only the initial problem, it could be even worse if all nodes in this
> aggregation were sending all types of packets to all others if an IP
> structuring (subnetting) were not respected.
> 
> The reason I'm staying personally away from tackling this problem is
> that in such an aggregation it is _first_ important to establish an L2
> connectivity graph, meaningfully.  Let me explain, if I were to build
> such an aggregated network for testing purposes with 802.11b, I would
> first and foremost make sure that each subnet of each MR has a different
> ESSID; this is in order for the LFN's of each MR's moving network be
> able to consistently talk to their respective MR; now, if the two moving
> networks have different ESSID's (and eventually different WEP keys),
> then the RA's sent by the child MR's ingress interface will not be seen
> at all by the parent MR's egress interface (even if in wireless range), 
> so no danger for the parent MR's to configure bad CoA and bad default route.
> 

In my opinion, when ARs and MRs use different ESSID, if an MR is getting 
into the larger mobile network, the MR need to select which ESSID it will 
use. That is also a confliction problem.

> If on the contrary the two moving networks have the same ESSID then not
> only the RA does not work properly, but a thousand other things won't work.
> 
> That's why, in my personal viewpoint, in a nested aggregation of moving
> networks it is important to first establish the meaningful L2
> connectivity first that respects the definition of a moving network
> itself (moving network is fixed subnet that moves homegeneously), on top
> of which it is easy to set up the working L3 topology.
> 
> Otherwise, if the L2 connectivity is not set correctly, then I think
> this goes out of scope of the moving networks concepts and becomes very
> much an manet issue, where everybody talks to everybody; that said, I
> don't think that in the manet world they've considered such fine detail
> as you do in your draft, but maybe they should.
> 
> > And how can we distinguish egress interface from ingress interface 
> > physically ?
> 
> Difficult to say indeed...
> 
> >> There is also a widely acknolwedged problem of "disconnected" 
> >> operation that was mentioned very early.
> > 
> > Could you breifly explain about "disconnected" operation ?
> 
> It's presented in detail in section B.5 "Example of disconnected
> operation issue" of draft-petrescu-nemo-mrha-03.txt (not expired).  It
> basically says that when two moving networks are nesting one under the
> other and the parent MR gets disconnected from the AR, then any LFN
> within the child MR's moving network is not able to talk to any other
> LFN of the parent MR's moving network (even though the two moving
> networks are physically attached).
> 
> Now, let me get back to your draft.  If I were to accept that that there
> is a problem of RA between child MR and parent MR, as you propose it,
> then I think that the proposed method is a potentially elegant solution
> to solve that problem (_if_ that is indeed a problem).  Also the
> Security Considerations section shows a good case of risk.
> 

I think, the risk of malicious RA is general problem of stateless address 
auto-configuration mechanism. So we need the method to secure the RA 
message.

> Section 1 second paragraph, 9th line, 10th word: I think you meant
> "ingress" and not "egress".
> 

Right, that is "ingress". That's my mistake.

> The Age field being on 3 bits it effectively limits the depth to 255
> levels no more, could be debatable.
> 

I think that the length of age field can varied. But do we need so many 
level of hierarchy?

> Overall, I could also say that the L2 solution I mentioned earlier
> (where different ESSID's are assigned to different moving networks) is
> transformed into a solution where the "Age" field is correctly used by
> every MR.  Both solutions could be correctly used, or abused :-)
> 
> Thanks again for asking me and feel free to discuss it on the nemo list.
> 
> Alex
> 

Thanks,
Hosik

---

From: Hosik Cho <[email-masked]>
Date: Fri, 27 Feb 2004 19:36:04 +0900

Hi Alex,

Please, read in lines.

Thanks,
Hosik

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 27 Feb 2004 20:22:01 +0100

Hosik Cho wrote:
> In my opinion, when ARs and MRs use different ESSID, if an MR is 
> getting into the larger mobile network, the MR need to select which 
> ESSID it will use. That is also a confliction problem.

By the definition in the draft, this is a confliction problem _only_ if
the two wireless interfaces have the same ESSID; not only will the
egress interface of the parent MR receive RA's from the ingress
interface of the child MR but the egress interface of the child MR too
will receive RA's from the ingress interface of the same MR (child); in
this way, there is a danger in that the egress interface of the child MR
might form a CoA based on the RA emitted by its own ingress interface.

But, if there are different ESSID's per each subnet (one ESSID for the
link of the parent MR's moving network and another ESSID for the link of
the child MR's link and yet another different ESSID for the AR) then I
think there is no confliction problem, because RA's sent by various
interfaces are visiblel only within the respective link.

> I think, the risk of malicious RA is general problem of stateless 
> address auto-configuration mechanism. So we need the method to secure
>  the RA message.

I think that securing RA's is tackled within SEND, maybe we can reuse
from them, or inform about the necessity of it as suggested by your
scenario.

>> The Age field being on 3 bits it effectively limits the depth to 
>> 255 levels no more, could be debatable.
> 
> I think that the length of age field can varied. But do we need so 
> many level of hierarchy?

Probably not in my oppinion, I am not aware of scenarios requiring more
than 4 levels...

So overall, I think that if we acknowledge that there is a danger in
that the parent MR egress interface accidentally uses the child MR's
ingress RA's, then there are distinctive possibilities to deal with it:

-define the right L2 reachability (for WLAN it's by using different
  ESSID's per subnet).
-use RA Age mechanism described in your draft.
-use SEND.

Or?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 27 Feb 2004 20:22:01 +0100

Or?

Alex