Subject: [nemo] Re: BU adds routes (was: Draft NEMO Agenda)

From: [email-masked]
Date: Wed, 06 Nov 2002 15:08:17 +0100 (MET)

Hi Vijay,

> 1. there is no way for the Home Agent to figure out which mobile
> router is allowed which mobile prefix. when it receives a binding
> update with the 'R' bit set, it creats a static route for the
> prefix to point to the home address of the MN.

Isn't that route already present in HA's routing table?  If it
weren't, then how did HA know how to talk to LFNs were the
mobile link at home?

I think that HA has entries in its classic routing table of the
form:

prefix of mobile link1  -> ll address of MR1
prefix of mobile link2  -> ll address of MR2

Otherwise HA wouldn't know to talk to LFNs when they are at home
and Mobile IPv6 is not used.

Or maybe I'm looking at it differently, please clarify?

Thanks,

Alex

---

From: Mattias Pettersson <[email-masked]>
Date: Wed, 06 Nov 2002 15:41:50 +0100

We had a nice little discussion around this on the Mobile-ip list end of
March-beginning of April 2001 called "Mobile Netwoks in MIPv6" and
another one in August 2001 called "Mobile Routers support without
optimization".

/Mattias

---

From: [email-masked]
Date: Wed, 06 Nov 2002 16:11:47 +0100 (CET)

> another one in August 2001 called "Mobile Routers support without

Sorry, I think I can't remember that discussion and the
playground archives seem to be down at this moment 
(says permission denied).

So in these discussions there was a conclusion about this?
Something like they decided that BUs must add routes is 
the best way to go?

Sorry if asking things that are already clarified.

Alex

---

From: [email-masked]
Date: Wed, 06 Nov 2002 17:03:28 +0100 (CET)

> another one in August 2001 called "Mobile Routers support without

Oh yes, I see what you mean, I remember now.  I found the threads
at tut.fi somewhere.  Geez almost two years now.

On a side note,
Mattias do you have any idea whether ICMP Redirects for HAs
was also discussed?  I need to read these.

Thanks for referencing these threads, there's much in it.

Alex
http://www.atm.tut.fi/list-archive/mobile-ip/threads.html

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 06 Nov 2002 10:42:53 -0800

hi Alex,

> weren't, then how did HA know how to talk to LFNs were the

when the MR was at home, it was running a routing protocol. so
either the Home Agent (if it runs a routing protocol) or the 
border router for the home link, had a route to the mobile
network's prefix.

but routes expire. and they expire fast. the route on the home 
agent or the border router is present only if the MR keeps sending 
routing updates. when the MR sends a binding update, the HA needs 
to add a route in case the route is not there. in case the route 
exists and the next hop points to a link local address, it needs 
to update the next hop to either MR_HoA or the tunnel interface 
(HA, MR_CoA). this is assuming section 6 of 
draft-kniveton-mobrtr-02.txt is not implemented.

a related question.

how often does the MR go home? (not often, IMO)

Vijay

---

From: Mattias Pettersson <[email-masked]>
Date: Thu, 07 Nov 2002 16:16:21 +0100

> was also discussed?  I need to read these.

I don't think anything like that was discussed.

/Mattias

---

From: Alexandru Petrescu<[email-masked]>
Date: 08 Nov 2002 12:07:03 +0100

Hi Vijay,

Vijay Devarapalli <[email-masked]> writes:
> but routes expire. and they expire fast.

Looks scary :-) Manually-added static routes don't expire, do they.

> the route on the home agent or the border router is present only if
> the MR keeps sending routing updates.

So why not MR keeping sending those classic RUs (Route Updates)
through the MRHA tunnel?  I mean, if the MR and HA were running a
dynamic routing protocol, they could continue running it when the MR
is not at home, but through the tunnel.

BUs sent by Mobile IP are sent each time MH moves, and each time the
MH acquires a new CoA, because that CoA changes.  Contrast this to
when MR moves, it changes its CoA but the prefix on the link stays
stable, it's not influenced by mobility.

Do you suggest that each classic BU containing a new CoA will also
contain the same old mobile link prefix?

Or do you suggest that refreshing BUs (those requested by BRs or by
local timeouts) might contain refreshing the same route?

> when the MR sends a binding update, the HA needs to add a route in
> case the route is not there. in case the route exists and the next
> hop points to a link local address, it needs to update the next hop
> to either MR_HoA or the tunnel interface (HA, MR_CoA).

I'm not sure I understand this very well but you seem to be on to
something.

The idea would be to have the MR_HoA equal the link-local address.

> how often does the MR go home? (not often, IMO)

Homeless Mobile IP?

I guess this depends to a large extent on the deployment scenarion.
Scenarios with a large backbone and many phones/PDAs moving around
(like in wireless telephony) suggest that MR is never at home.  But
scenarios with slices of LANs moving very rarely and very remotely
(when travelling to a conference) suggest that MR is at home most of
time, especially when market conditions are adverse.

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 08 Nov 2002 10:30:40 -0800

> Looks scary :-) Manually-added static routes don't expire, do they.

why would you manually add a static route? this will not scale IMO.

1. when the MR is it at home, it is running some kind of routing
protocol. so the home agent or the border router have routes to 
it.

2. when the MR is not at home and does not run a routing protocol
through the bi-directional tunnel, a route to the mobile network
is created when the MR sends a BU to the home agent.

3. when the MR is not at home, but does run a routing protocol
through the bi-directional tunnel, a route to the mobile network
is created when the MR sends routing updates.

why do you need manual intervention to add static routes to each
mobile router?

and when I said routes expire, I was talking about routes created
through (1), (2) and (3).

> is not at home, but through the tunnel.

the MR is shut off!!! my cell phone (assuming its the MR for my PAN)
is not going to be up and running all the time.

> > how often does the MR go home? (not often, IMO)

why not? if the MR is a cell phone, it almost never goes home. if 
the MR is a train/plane/ship, its the same. if they are at home, 
you can be sure that there are no passengers on board :-)

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 08 Nov 2002 11:01:42 -0800

hi,

a clarification.

> you can be sure that there are no passengers on board :-)

not the Homeless Mobile IP as specified by Ericsson Nomadic Lab. :-)
I am just referring to base MIPv6, when MN does not go home often.

Vijay

---

From: Alexandru Petrescu<[email-masked]>
Date: 08 Nov 2002 20:56:06 +0100

Vijay Devarapalli <[email-masked]> writes:
> > the MR is a train/plane/ship, its the same. if they are at home, you
> > can be sure that there are no passengers on board :-)
> 

Yes, I understand that.

Alex

---

From: Alexandru Petrescu<[email-masked]>
Date: 08 Nov 2002 20:55:01 +0100

> why would you manually add a static route? this will not scale IMO.

Ah, correct, scalability, again.  This will not scale, that will not
scale.

It is correct, manually added routes will not scale.

And I can find other things that don't scale and are used commonly.
How many MRHA tunnels can one have on a router when that tunnel is an
interface.

> protocol. so the home agent or the border router have routes to 

It is possible to have an MR at home and not run routing protocol.  I
mean it is possible these days and you're surely keeping this in mind,
but overlooking it somehow, that's why I'm continuing the discussion
to see why.

> through the bi-directional tunnel, a route to the mobile network is
> created when the MR sends a BU to the home agent.

Yes, as in draft-kniveton.

So the routing table is updated both by BUs and by RUs.  How about the
binding cache being updated both by BUs and RUs.

> why do you need manual intervention to add static routes to each

When the MR is at home and the HA is a one-interface machine then
there will not be manual addition to the HA's routing table.  The BR
will send ICMP redirects, so the HA's routing table is modified
dynamically.

> through (1), (2) and (3).

Yes, correct, I understand, but I believe the ICMP redirects where
overlooked.

> is not going to be up and running all the time.

If MR is shut off then HA doesn't need a routing table entry either(!!!).

> why not? if the MR is a cell phone, it almost never goes home.

Vijay, I certainly agree with this direction of homeless reasoning.
You're right, when MR is cell phone and deployment is 3GPP-like then
MR never at home.  I agree.

I also must say that I truly appreciate the lessons I learned from the
implementation experience as exposed in draft-kniveton.  I'm just
trying to clarify some questions I have and you might be entirely
right that prefixes are needed in the BUs.

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 08 Nov 2002 13:34:17 -0800

> but overlooking it somehow, that's why I'm continuing the discussion

yes. it is possible, though I wouldnt manually create a route for 
a router, which I know is mobile and could move away from the home
link.

here I think your ICMP redirect mechanism is very useful. I am
still beginning to understand this. 

> binding cache being updated both by BUs and RUs.

binding cache is updated only by BUs.

> If MR is shut off then HA doesn't need a routing table entry either(!!!).

right. thats why the HA needs to check if there is a route to 
the mobile network when it receives a binding update from the
mobile router. if a route is not present, it has to create one.

the home agent also has to make sure that packets meant for the 
mobile network reach the home agent on the home link. your ICMP 
redirect mechanism would be very useful here. the home agent 
sends an ICMP redirect for the mobile network prefix to point 
to itself. every router on the home link update their routing 
tables to point to the home agent. this would work right?

regards
Vijay

---

From: Mattias Pettersson <[email-masked]>
Date: Sat, 09 Nov 2002 16:49:44 +0100

> through (1), (2) and (3).

I fully agree. This is exactly the scenario I see.

/Mattias

---

From: Alexandru Petrescu<[email-masked]>
Date: 12 Nov 2002 17:16:08 +0100

> a router, which I know is mobile and could move away from the home

Yes, the possibility that that router disappears is rather high.
Still, the kind of route we're talking about doesn't reflect change in
the CoA.  In other words, the route is "static", towards a fixed
prefix, through a fixed ll address.  When MR changes its CoA, the same
route is there, no change in the route.  Meaning that if the router is
continuously changing its CoA, but always connected, the route we're
talking about doesn't change, it's the same.

> binding cache is updated only by BUs.

Yes, I understand that.  And I'm trying to suggest that BUs that
update the routing table is like RUs that update the binding cache.

In a home domain the routing is currently done by RUs that update
routing tables.  When some home subnets or hosts (non-mobile)
disappear, or some others (also non-mobile) appear, RUs updating
routing tables manage to keep routing consistent.  Add network
mobility to the picture.  Notice that routing tables will be updated
both by RUs and by BUs.  Ensure that those updates are consistent.

This is probably more of an administrative issue, than a
standardization issue, I agree with that; but I think that separating
the semantics of RUs and BUs gives less place to administrative
errors.

> mobile router. if a route is not present, it has to create one.

Yes, something like that.  Note though that if the HA receives a BU
from MR, it could as well receive an RU.

> tables to point to the home agent. this would work right?

I think the HA will get all packets for the mobile network as long as
HA defends the ll of the router.  The problem will be how to route
those packets towards the MR CoA, MR needs the route you're talking
about.  HA could get that route by various means, as you explained,
plus the ICMP redirect.  I think we're synchronized here.

I dont understand why do you suggest that HA sends redirects though.

I was thinking that HA sends redirects when the MR is not at home and
HA represents MR, so it takes the role of the MR-at-home and sends
that redirect (when the MR would need to send it).  Another
possibility would be for the MR to send the redirects on the home
link, through the MRHA tunnel, when MR is not at home.  All this, in
case that MR would send a redirect when it were at home.

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 12 Nov 2002 10:40:52 -0800

Hi Alexandru,

> case that MR would send a redirect when it were at home.

take the following scenario. lets assume the MR is away from home,
but has an active binding for both MR_HoA and MR_LinkLocal at the
HA. a border router on the home link has a route to the mobile 
network pointing to the link local address of the MR. when a packet
arrives at the border router meant for the mobile network, it is
sent to the home agent because HA is proxying the link local address
of the MR. the home agent then tunnels it to the MR through the 
tunnel interface (HA, MR_CoA).

now assume the mobile router is switched off. after some time the
binding cache entries at the HA expire. the HA stops proxying the 
link local address of the MR. the route at the border router 
*expires* (I dont believe much in static routes).

the MR comes up and sends a binding update to the HA. the HA then
starts proxying MR_LinkLocal and MR_HoA again. some node in the
mobile network starts a session with a CN. there would be packets
coming from the CN (meant for the mobile network) to the border
router. the border router does not have a route to the mobile 
network. packets are dropped!!! how do we handle this? I was
trying to figure out if the ICMP redirect mechanism could be used 
here by the HA to inform the border router that it can reach the 
mobile network.

the whole thing would be much more simpler if the HA becomes the
default router on the home link for all mobile routers at all 
times.

comments?

regards
Vijay

---

From: Miguel Catalina Gallego<[email-masked]>
Date: Tue, 12 Nov 2002 20:20:11 +0100

Hi Vijay,

Vijay Devarapalli wrote:
> network. packets are dropped!!! how do we handle this?

If the routes have expired at the BR it will not be able to route the 
packet, even if the HA has the correct routes.

Maybe it is reasonable to assume that the MR will send RUs when 
reconnecting after a long time disconnected.

> I was

It is reasonable, IMO.

> default router on the home link for all mobile routers at all 

The issue is still the same, IMO. If the routes expire at the BR then we 
need a way of refreshing them. Either the HA propagates the routing 
information it has received in a BU or through an RU from the MR, or the 
MR sends RUs directly to it. In any case the routes in the BR will not 
refreshed immediately.

Also, maybe the HA could treat routes pointing to the MR in a different 
way and avoid making them expire (or setting different expiration 
timeouts). The HA would continue to send RUs to the BR with the routes 
to the MR. If the BU to the MR has expired, then the HA should just drop 
  any packets it receives. This mixes binding cache and routing table a 
little bit, I am not sure if it is a good idea.

Regards,

	Miguel

-- 
Miguel CATALINA GALLEGO
Centre de Recherche de Motorola - Paris
[email-masked]
Tel: +33 (0) 1 69 35 25 41

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 12 Nov 2002 11:57:27 -0800

Hi Miguel,

I guess I wasnt clear in my earlier mail. we were dicussing only
one particular scenario. heres the text from an earlier mail.

> is created when the MR sends routing updates.

we were discussing (2). if the route to the mobile network was not
created at the HA through a routing protocol update, it is not
included in HA's routing protocol updates. so we need a mechanism
here for the HA to inform the border router that it can reach the
MR. so I was trying to see if ICMP re-directs could be used here.

for (3), it works naturally. when the HA receives routing updates
from the MR, it re-broadcasts the routes in its routing updates.
the border router then creates a route to the mobile network to
point to the home agent.

regards
Vijay

Miguel Catalina Gallego wrote:
>> HA. a border router on the home link has a route to the mobile network 
>> pointing to the link local address of the MR. when a packet
>> of the MR. the home agent then tunnels it to the MR through the tunnel 
>> interface (HA, MR_CoA).
>>
>> binding cache entries at the HA expire. the HA stops proxying the link 
>> local address of the MR. the route at the border router *expires* (I 
>> dont believe much in static routes).
>>
>> router. the border router does not have a route to the mobile network. 
>> packets are dropped!!! how do we handle this?
> 
> 
>> trying to figure out if the ICMP redirect mechanism could be used here 
>> by the HA to inform the border router that it can reach the mobile 
>> network.
> 
> 
> It is reasonable, IMO.
> 
>> default router on the home link for all mobile routers at all times.
> 
>

---

From: Alexandru Petrescu<[email-masked]>
Date: 13 Nov 2002 13:36:52 +0100

> network. packets are dropped!!! how do we handle this?

Maybe TCP will retransmit?

I see your point.  Propagation of disappearing routes can hurt indeed.
If the MR is turned off for an extended period of time then BR will
loose the route, and BR2 and BR3 further up the stream will loose them
as well.  Up to BR4 that has a prefix covering the prefix of MR.

Then when MR is back on, it might take some time to propagate the
re-addition of this old route within the entire domain.  And during
all this time packets from CN towards LFNs are being dropped.

But.  Maybe this is no different than MR being at home and being
turned off for other reasons than mobility.  If MR is at home and is
turned off, then the routing protocol will manage this situation, for
better or for worse.  If MR is _not_ at home and is turned off, it
must be as if it were at home and turned off, so it is the same
routing protocol that will manage this, for the same better or worse.
Maybe we're on the same wavelength here.

> I was trying to figure out if the ICMP redirect mechanism could be
> used here by the HA to inform the border router that it can reach
> the mobile network.

Aha, I see, yes might be interesting.  So with this, even if the MR is
turned off, the HA would still get packets addressed to LFNs and might
have an opportunity to cache them until the MR is turned back on?  A
sort of optimization?

> default router on the home link for all mobile routers at all 

I guess so.  The problem is that we can't turn it into a
requirement...

Alex

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 13 Nov 2002 15:12:28 +0100 (CET)

> why would you manually add a static route? this will not scale IMO.

That depends on how you are going to determine which MR is authorized
to inject routes for which prefixes.

The simple way to do this is to have a table with MR identities 
(in the form of the security associations for the tunnels or something
else with cryptographic binding to the actual MR), and a list
of allowed prefixes the MR can advertise.

That information is exactly the information you need for
creating the static routes.

Of course, I can see a need in some cases for being able to automate the
initial assignment of prefixes to MRs. Perhaps the ideas in the prefix
delegation space in the IPv6 WG can be used for this, assuming there is
sufficient understanding of the security issues of doing such prefix
delegation to an MR that is away from home.

  Erik

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 13 Nov 2002 09:51:33 -0800

> as well.  Up to BR4 that has a prefix covering the prefix of MR.

actually no. if we assume that the mobile router's prefix belongs 
to the home link prefix, its only the border router in the home 
link. I think it is a safe assumption to make. so BR2 and BR3 
alway route to BR1 whenever they get a packet for the mobile 
router's prefix. it shouldnt matter if the MR is up or shut off.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 13 Nov 2002 09:56:25 -0800

Miguel Catalina Gallego wrote:

> Ok, now I see. It seems reasonable. But ICMPv6 (RFC2461) seems quite
> strict regarding the validation of ICMP redirects. Also, if the routes
> to the Mobile Network via the MR have expired redirects would not be
> enough, right?

if the route to the Mobile Network has expired on the HA, there is
no need to keep the route active on the border router either (IMO).
the mobile router is simply unreachable.

> Is the HA running a routing protocol with the BR? If it is, then it 
> would send an unsolicited RU to the BR.

this unsoliticied RU will not contain the route to the Mobile 
Network, if the HA does not have a valid route to the Mobile
Network.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 13 Nov 2002 10:15:56 -0800

> of allowed prefixes the MR can advertise.

this is what we do in our implementation. but the static route is
not created until the HA receives a binding update from the MR. and
when the MR deregisters or when the binding cache entry expires, 
the static route is removed. but we dont create it manually.

there are two scenarios in draft-kniveton-mobrtr. in the first, the
MR does not run a routing protocol through the bi-directional tunnel.
so we do the above in the first scenario. in the second scenario, the 
MR sends routing updates through the bi-directional tunnel. creating a
route is not tied to the binding update in this scenario. but the 
authorization check (to see if a particular MR is allowed a particular 
prefix) is still needed.

Vijay

---

From: Alexandru Petrescu<[email-masked]>
Date: 13 Nov 2002 19:29:59 +0100

> of allowed prefixes the MR can advertise.

I don't understand the need to authorize which MR advertises which
prefix.  I was thinking that MRs are trusted by the HA because they
had that IPsec tunnel.  So if the MRs share keys with the HA then they
can also advertise routes through the HA?

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 13 Nov 2002 10:42:29 -0800

> can also advertise routes through the HA?

lets assume there are two MRs, MR1 and MR2. what prevents MR2 from
disrupting traffic to MR1 by advertising routes for MR1's mobile
network to point to itself? Both MR1 and MR2 have security 
associations with the HA.

Vijay

---

From: Alexandru Petrescu<[email-masked]>
Date: 13 Nov 2002 19:50:28 +0100

> associations with the HA.

Aha, so this table would protect against a threat where one MR attacks
another MR, both of the same HA.

But this threat is valid even when no mobility is in place.  Assume
R1, R2 and HA are neighbouring routers.  Let's say that both R1 and R2
are trusted by HA.  Then R1 and R2 can attack each other's prefix,
fooling HA to believe what it shouldn't.

I'm not saying this threat is invalid, just trying to understand
whether that authorization check is an absolutely needed feature or
something we could live with, and still make the mobile networks work
(w/o taking attackers in mind).

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 13 Nov 2002 11:11:20 -0800

> fooling HA to believe what it shouldn't.

this is where the admin steps in :-). but seriously, it is a not
a threat in the above, but becomes a threat when the mobile routers
are away from the home link. routing on a link is strictly controlled
by the admin. infact, in many networks people run RIPng/OSPFv3 without 
any protection.

regards
Vijay

---

From: Alexandru Petrescu<[email-masked]>
Date: 13 Nov 2002 20:20:34 +0100

Vijay Devarapalli <[email-masked]> writes:
> this is where the admin steps in :-).

Ah they are helpful sometimes those humans aren't they.

> but seriously, it is a not a threat in the above, but becomes a
> threat when the mobile routers are away from the home link.

Vijay, is the same attack possible with Mobile IPv6 for hosts where
MH1 claims the home address of MH2, of the same HA?  I must recognize
I haven't read the draft.

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 13 Nov 2002 11:32:01 -0800

> I haven't read the draft.

yes it is. it is recognized as a threat. thats why it says the IPsec
SA created between the MN and HA should be tied to the home address
of the MN. one way of doing this would be to include the home address
in the Subject Altname field of the certificate, if certificate based
automatic keying is being used by MN and HA.

in general, I think this authorization check need not be a MUST. but
others might have a different opinion.

Vijay

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 14 Nov 2002 10:09:30 +0100 (CET)

> can also advertise routes through the HA?

For the same reason that the HA MIPv6 needs to associate a given IPsec SA
with the home address of the MN - to prevent one user of the HA from stealing
the packets for another user of the same HA.

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 14 Nov 2002 10:17:36 +0100 (CET)

> (w/o taking attackers in mind).

Alex, 
this makes an excellent point for
 - the WG needing a threat analysis draft ASAP
 - the WG needing to discuss the threats in detail

And my personal answer to your question is that it
depends on whether there is an admin boundary between the HA and MRs or
not. If the same organization controls the HAs and MRs (and the MRs are
hardened so they can't be subverted even though they might have less physical
security than nodes physically on the home link) then the threat might
not be of concern.
But when the MR is operated by a different administration than the HA
then I think this threat needs to be taken very seriously.

  Erik

---

From: Alexandru Petrescu<[email-masked]>
Date: 14 Nov 2002 21:01:01 +0100

> then I think this threat needs to be taken very seriously.

In these conditions, this should indeed be taken very seriously.  Here
are some issues I could think of (I wouldn't quite call them threats
since it's very high-level):

-MR1 claiming MR2's prefix is only the tip of the iceberg, because it
 only attacks MR2 and only the nodes on the mobile network of MR2.

-MR1 could also claim a better default route at the home domain, thus
 deviating all Internet traffic of the the HA, of all the MRs, of the
 BR and of all the nodes on the home link.

-MR1 could do worse by pretending to own a prefix that is out of the
 home link but still within the domain that is controlled by the
 administrative entity that administrates the home domain.

These three risks appear when MR is physically away from home and
connected to the home link through the HA.  If MR is physically at
home, other risks may arise: in a home network deployment where MR, HA
and BR run a dynamic routing protocol, protected with the same shared
key, and where a "MR-route check table" is used by HA to ensure that
only "official" routes are advertised by MR, and if it is possible for
an attacker MR to connect physically on the other side of the BR, then
MR could take advantage of that key and advertise whatever routes it
pleases.

In all the above, the assumption is that MR is an attacker; but the
other possibility could be when the HA is compromised and attacks MR.
(this is somehow equivalent to MH connecting to an AR, where the
problem is not only how the MH authenticates to AR, but also how is
the MH sure that the AR is legitimate.)

Also, a case where MR1 and MR2 both belong to the same HA, but they're
away and nested MR1 under MR2: we should make sure that the MRHA
tunnels (or the MRTP protocols) work fine (maybe they do without me
worrying).  And if work, and three different administrative entities
(MR1's, MR2's and HA's), make sure no new threats, looks tough :-)

Alex