Subject: [nemo] RE: DND test [was Assigning the same prefix to multiple MRs]

From: "Soliman Hesham" <[email-masked]>
Date: Thu, 18 Mar 2004 08:03:45 -0500

> Agreed:
 >   The test was not designed yet. The requirement for the 
 > test is still
 > not agreed upon. So if this thread ends up anywhere, maybe it's to an
 > answer to that question: Is there a need for a Duplicate Network
 > Detection test that would check that when a prefix is 
 > registered twice,
 > you end up on the same link for both registrations?

=> Hmmm, interesting question. However, I think we're
skipping a few steps in attempting to answer this question.
Your question is assuming that the preferred solution for 
a multihome monet (sorry I just don't thing nemo makes english
sense in this sentence) is to assign the same MNP to
all MRs. Given this assumption, it's natural to ask the
question above. 

On the other hand, if we ask: What is the best interim 
step for multihoming in nemo, we might end up with
a different solution and consequently a different set of 
questions. I preferred to ask the latter question than
the first. 

Personally, I think it's a lot cleaner to have one prefix
per MR and somehow solve the ingress filtering problem.
This is not so difficult in the case where the 2 MRs
belong to the same home domain/link. For instance, an 
ISP might not filter (in the MR's HA) on any of the 
prefixes that are assigned to its domain. So basically
it forwards any packet coming from any prefix derived
from ISP_PREFIX::/26. This would solve the simple multihoming
case where 2 MRs belong to the same home admin domain.
I think this will solve the problem with the scenarios 
that you mention, i.e. plane, train, bus ...etc.

Do you think this will work? This requires hardly any
changes to the spec. We can clearly do without changing
anything, except for mentioning that 2 MRs do not share 
the same prefix. I misstated that before to say 1 prefix
per MR, when what I really meant was two MRs do not share
the same prefix.

Hesham

 > Pascal

---

From: Ryuji Wakikawa <[email-masked]>
Date: Fri, 19 Mar 2004 00:01:26 +0900

Hello Hesham

There is a draft draft-ng-nemo-multihoming-issues-03 about multihomed
NEMO pb statement. During the Seoul meeting, we all agreed on the
scenarios described in the slide. And two of scenarios are actually (N
MRs, 1 HA, and 1 Prefix) and (N MRs, N HA, and 1 Prefix).  I want to
keep the above two scenarios.  It is too restrict to remove one of
scenario at this time.

I don't know whether ISP wants the below configuration for ingress
filtering.  How does each HA know which prefixes are assigned to a
mobile network(i.e. two MRs in your case)? 
Do you assume using prefix table?  
ISP can not stop a malicious MNN sending packets with a wrong prefix
which is within ISP-prefix. The example scenario is that a mobile
network has ISP_PREFIX-A,-B, but MNN send DoS packet with the source
address of ISP_PREFIX-C.

Even we remove the case where 2 MRs share the same mobile network
prefix, we still need to confirm whether there is duplicated MR for
the prefix or not, like MIP6 has DAD mechanism for HoA. It is worth to
clear this part, but I want to keep multihoming scenarios open.

regards,
ryuji

At Thu, 18 Mar 2004 08:03:45 -0500,

---

From: Ryuji Wakikawa <[email-masked]>
Date: Fri, 19 Mar 2004 00:01:26 +0900

Hello Hesham

regards,
ryuji

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 24 Mar 2004 12:50:20 +0100

Hi Hesham,

[...]

> per MR and somehow solve the ingress filtering problem.

If i understand the scenario that you are proposing, there are more
problems, not only ingress filtering.

Let me see if i get this right:
The scenario that you are proposing would be the following

             P::/26
      ----|-------------- Home network
          |
        +---+
        |HA |
        +---+
  route  |  \ route to
  P:P1:: |   \ P:P2::
         |    \
      +---+   +---+
      |MR1|   |MR2|
      +---+   +---+
  P:P1::|        |P:P2::
  ---------------------- Mobile network

So, each of the MR of the NEMO has one prefix assigned and announces it in
the NEMO.
The HA has one prefix registered per each MR, so this means that it forwards
packets addressed to P:P1:: only through MR1 and  the HA forwards packets
addressed to P:P2:: only through MR2
Is this the configuration that you are proposing?

If this is so, this presents all the problems of multiaddressing, i guess.
In order to be reachable through both MR, the hosts within the NEMO will
have to configure two addresses, one with P:P1:: and another one with P:P2.
This is so because if they only configure an address with P:P1:: they will
be only be reachable through MR1, since the HA only has MR1 registered for
this prefix.

Well this multiaddressing configuration presents complex challenges, for
instance how do you preserve established communications when the MR that you
were using fails.
Also, in case that one of the MR is down, you need a smart way to select the
source address that is working on the reverse path, which imposes new
mechanisms in the MNN

So, in brief, if i understand correctly, this configuration poses the full
multihoming problem in a configuration that didn't suffered it before.

I am sure that i don't fully grasp the complete problem of detecting a
duplicate prefix in the same HA that you are discussing, so i cannot make
any consideration about the solution for this problem, but the proposed
configuration really presents complex issues.
Of course, once that multi6 develops a solution for the general case, it
should also cover this case too.

Regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 24 Mar 2004 12:50:20 +0100

Hi Hesham,

[...]

             P::/26

Regards, marcelo

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Mar 2004 15:29:25 +0100

I think I agree with Marcelo's interpretation of multi-homing for MR
(below) and with the conclusion. I also think that it is important to
stress that the picture he depicted only shows MR at home and by
considering MR at home there are already some problems as he
mentioned. My addition is that only when we know how to solve these
problems of multi-homed MRs at home can we look into what NEMO brings new.

Alex

marcelo bagnulo wrote:
> Let me see if i get this right: The scenario that you are proposing
> would be the following
> 
>              P::/26
> So, each of the MR of the NEMO has one prefix assigned and announces
>  it in the NEMO. The HA has one prefix registered per each MR, so
> this means that it forwards packets addressed to P:P1:: only through
> MR1 and the HA forwards packets addressed to P:P2:: only through MR2
> If this is so, this presents all the problems of multiaddressing, i 
> guess. In order to be reachable through both MR, the hosts within the
>  NEMO will have to configure two addresses, one with P:P1:: and 
> another one with P:P2.
> 
> This is so because if they only configure an address with P:P1:: they
>  will be only be reachable through MR1, since the HA only has MR1 
> registered for this prefix.
> 
> Well this multiaddressing configuration presents complex challenges,
>  for instance how do you preserve established communications when the
>  MR that youwere using fails. Also, in case that one of the MR is 
> down, you need a smart way to select the source address that is
> working on the reverse path, which imposes new mechanisms in the MNN
> 
> So, in brief, if i understand correctly, this configuration poses the
>  full multihoming problem in a configuration that didn't suffered it 
> before.
> 
> I am sure that i don't fully grasp the complete problem of detecting 
> a duplicate prefix in the same HA that you are discussing, so i 
> cannot make any consideration about the solution for this problem, 
> but the proposed configuration really presents complex issues. Of 
> course, once that multi6 develops a solution for the general case, it

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Mar 2004 15:29:25 +0100

Alex

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 24 Mar 2004 17:11:16 +0100

Hi Alex

> stress that the picture he depicted only shows MR at home and by

Actually, the links between the HA and the MRs were supposed to be the
tunnels, so i was not considering that the nemo is at home.
The problems that i was describing exist when the nemo is away form home, i
am not sure that they also occur when the nemo is at home, i guess this will
depend on the configuration of the home netwrok. I mean , if the nemo is at
home, it doens't use the HA to communicate, right?

Sorry for my poor drawing, that may have generated the confusion

Regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 24 Mar 2004 17:11:16 +0100

Hi Alex

Regards, marcelo

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Mar 2004 17:27:11 +0100

marcelo bagnulo wrote:
> Actually, the links between the HA and the MRs were supposed to be 
> the tunnels, so i was not considering that the nemo is at home.

I see, sorry for the confusion!

> I mean , if the nemo is at home, it doens't use the HA to
> communicate, right?

Sidenote, depends on who you're asking; in my setting it is true; in
other settings the HA is colocated with the BR (the one connecting the
home link to the Internet) so MR will go through HA even if at home but,
of course, not through tunnels.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Mar 2004 17:27:11 +0100

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Mar 2004 17:30:01 +0100

marcelo bagnulo wrote:
> another one with P:P2. This is so because if they only configure an
> address with P:P1:: they will be only be reachable through MR1, since
> the HA only has MR1 registered for this prefix.

This is, as you say, a problem of having a host to confnigure two 
addresses; it is not a NEMO problem.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Mar 2004 17:30:01 +0100

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Mar 2004 17:36:51 +0100

Marcelo, I think that a dynamic routing protocol on MR and HA's can help
to obtain failure recovery when one of the tunnels is broken (because
respective wireless link unavailable, or other reason).

I assume a MR with two egress interfaces and one ingress interface; I
assume each egress interface has its own Home Address and MR maintains
two MR-HA tunnels: one to HA1 and one to HA2; I assume that HA1, HA2 and
MR run a dynamic routing protocol between them; I also assume that there
is only one prefix assigned to the moving network.

In this case, I think that a dynamic routing protocol can dynamically
manage to continue communication of LFN (LFN has only one address) even
though one of the links corresponding to one of the tunnels fails.

What do you think?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Mar 2004 17:36:51 +0100

What do you think?

Alex

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 24 Mar 2004 18:22:33 +0100

> addresses; it is not a NEMO problem.

Yes, but if we impose that when there are multiple MR you need to have
multiple prefixes one per MR, you are imposing all the problems of
multiaddressing in a configuration that perhaps don't require multiple
addresses.

My point is that if we can avoid multiaddressing, we are avoiding lots of
complex problems, so perhpas we shoudl try to do it at least in some of the
scenarios.

Makes sense?

Regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 24 Mar 2004 18:22:33 +0100

Makes sense?

Regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 24 Mar 2004 18:51:24 +0100

> though one of the links corresponding to one of the tunnels fails.

indeed.
That is the type of solution that you would have in a fixed subnetwork with
multiple routers connecting to the site.
That is what the IGPs are designed to do so that is the tool.
Two issues here:

First, how to handle the split network problem that Hesham is considering?
When the network splits, one of the MR should stop advertising the nemo
prefix, i guess, so some setting for this should be required.

Second, this is a general nemo issue about security when using IGPs in a
nemo environment, do you think that it is acceptable to run an IGP between
the MR and the HA?

Regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 24 Mar 2004 18:51:24 +0100

indeed.

Regards, marcelo

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Mar 2004 19:07:23 +0100

marcelo bagnulo wrote:
>> I assume a MR with two egress interfaces and one ingress interface;
>> I assume each egress interface has its own Home Address and MR
>> maintains two MR-HA tunnels: one to HA1 and one to HA2; I assume
>> that HA1, HA2 and MR run a dynamic routing protocol between them; I
>> also assume that there is only one prefix assigned to the moving
>> network.
>> 
>> In this case, I think that a dynamic routing protocol can
>> dynamically manage to continue communication of LFN (LFN has only
>> one address) even though one of the links corresponding to one of
>> the tunnels fails.
 >
> indeed. That is the type of solution that you would have in a fixed
> subnetwork with multiple routers connecting to the site. That is what
> the IGPs are designed to do so that is the tool.

I think IGP can be used between HA's and MR even when MR is not at home,
because MR still belongs to the home domain (through the tunnels), so
the I in IGP is still valid.

> Two issues here:
> 
> First, how to handle the split network problem that Hesham is 
> considering? When the network splits, one of the MR should stop 
> advertising the nemo prefix, i guess, so some setting for this should
>  be required.

"Split network problem" could you please formalize somehow?  Do you mean 
a moving network nesting under another moving network and then 
separating?  What exactly is "split network"?  I've read most of 
Hesham's emails attentively, but can't remember it.  Maybe a separate 
message with subject line saying "split network problem" will help me.

> Second, this is a general nemo issue about security when using IGPs
> in a nemo environment, do you think that it is acceptable to run an
> IGP between the MR and the HA?

I think there is no major security issue in using IGP in a NEMO 
environment as long as that IGP is used between MR and HA's and over the 
MR-HA tunnels.  I'm definitely not proposing to have MR to have direct 
IGP interactions with the other IGP that might happen to run in the 
visited domain (e.g. I'm _not_ proposing MR to do IGP with AR).

No?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Mar 2004 19:07:23 +0100

No?

Alex

---

From: "marcelo bagnulo" <[email-masked]>
Date: Thu, 25 Mar 2004 12:25:47 +0100

> the I in IGP is still valid.

Yes, i agree with you.

> message with subject line saying "split network problem" will help me.

next mesages...

> MR-HA tunnels.

Well, the point here is to make sure that the MR only announces the prefixes
that it is allowed too, and does not tries to hijack the traffic from other
prefixes. This is general concern for routing protocol security, but perhaps
in this case is a bit more real. I guess that you can fix that by imposing
the HA to inspect all the announcements of the MR to verify that it only
announces what it is allowed. This is at least more load to the HA. But the
bottom line is that you not really needing an IGP here, since you don't want
to discover the topology. The announced prefixes are only those that are
allowed. What you want is a mechanisms to detect failures. Perhaps there are
simpler options and more effective, like draft-katz-ward-bfd-00.txtto  (or
just a ping) to do this. OTOH, i think that IGP seems like a good option
when the same prefix is reachable through two HA. You can use IGP and the
metrics to select which HA and also to balance traffic.

So, summarizing, there are two applications of the IGP:
- HA-MR failure detection
- Selection among different HAs in the home network.

  I'm definitely not proposing to have MR to have direct
> visited domain (e.g. I'm _not_ proposing MR to do IGP with AR).

agree.

Regards, marcelo

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 25 Mar 2004 13:41:28 +0100

marcelo bagnulo wrote:
>> environment as long as that IGP is used between MR and HA's and 
>> over the MR-HA tunnels.
> 
> Well, the point here is to make sure that the MR only announces the 
> prefixes that it is allowed too, and does not tries to hijack the 
> traffic from other prefixes.

Ok.

> This is general concern for routing protocol security, but perhaps in
>  this case is a bit more real. I guess that you can fix that by 
> imposing the HA to inspect all the announcements of the MR to verify
>  that it only announces what it is allowed.

The HA inspecting all announcements of the MR, and comparing to the
routes it itself owns about MR (probably introduced by admin in an
existing config file and routing table) is one way of checking.  For
NEMO, another way of checking is the NEMO-specified Prefix Table at HA
where the Prefix Table is actually a new structure but which is most
probably filled by the same admin.

> This is at least more load to the HA. But the bottom line is that you
>  not really needing an IGP here, since you don't want to discover the
>  topology.

I think IGP or EGP or any routing protocol is not only used for topology
discovery but most importantly for route maintenance when links fail.
But this is of course a matter of interpretation.

> What you want is a mechanisms to detect failures. Perhaps there are 
> simpler options and more effective, like draft-katz-ward-bfd-00.txt

I just can't find it, neither 01 nor 02, nor 03, is it an RFC.

I have an idea about how route failures are detected in OSPF and RIP
(various flavors) and I think they can be used with the NEMO base support.

> (or just a ping) to do this. OTOH, i think that IGP seems like a good
>  option when the same prefix is reachable through two HA. You can use
>  IGP and the metrics to select which HA and also to balance traffic.
> 
> So, summarizing, there are two applications of the IGP: - HA-MR 
> failure detection - Selection among different HAs in the home 
> network.

I guess so. So coming back to the NEMO multi-homing-related problem,
where is the IGP _not_ sufficient?

Alex

---

From: "marcelo bagnulo" <[email-masked]>
Date: Thu, 25 Mar 2004 12:25:47 +0100

Yes, i agree with you.

next mesages...

agree.

Regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Thu, 25 Mar 2004 15:56:53 +0100

> where is the IGP _not_ sufficient?

No, i think that an IGP can work for this.
My concern is whether this is best option. I mean, the HA doesn't have to
discover the prefixes behind the MR since it already knows them. so using a
IGP would impose the additional burden of having to inspect the packets
looking for IGP messages and then inspecting the content of such packets.
If you use a simple ping to detect reachability between the MR and the HA
you will obtain the same functionality with a lower cost, i guess.
Of course, IGP are already there.
I do agree that using IGP to inform about the different paths through
different HAs within the home network is fine.

Regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Thu, 25 Mar 2004 15:56:53 +0100

Regards, marcelo

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 25 Mar 2004 13:41:28 +0100

Ok.

Alex

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 25 Mar 2004 16:07:54 -0800 (PST)

> looking for IGP messages and then inspecting the content of such packets.

That doesn't make sense. The routing protocol messages would be addressed
to the routing neighbor i.e. the address of the HA and MR respectively.

> you will obtain the same functionality with a lower cost, i guess.

A naive implementation of that would actually double the number of
packets needed for a particular failure detection time limit; each end would
end up needing to ping the other every N seconds in order to declare the
path dead in e.g 3N seconds; each ping in each direction implies 4 packets
(request+reply in each direction).
The hello protocol in an IGP uses half as many packets since both ends
find out whether the peer has heard them (there is a "I heard you" bit in
the hello messages; each end sends a packet every N seconds.

> Of course, IGP are already there.

Yes, and reinvented wheels might not be as good as the existing wheels :-)

There has been proposals for a separate "hello/reachbility test" protocols
in the past, but I don't know if these proposals have seen enough traction.

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 25 Mar 2004 16:07:54 -0800 (PST)

Erik

---

From: "marcelo bagnulo" <[email-masked]>
Date: Fri, 26 Mar 2004 12:01:27 +0100

> to the routing neighbor i.e. the address of the HA and MR respectively.

You are right, it doesn't. Thanks for clearing my confusion.

> in the past, but I don't know if these proposals have seen enough

Yes, i was more worried becuase of my bogus need to inspect all packets. I
guess that an IGP would do just fine here.

Regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Fri, 26 Mar 2004 12:01:27 +0100

Regards, marcelo