Subject: [mobile-ip] Security on Local "Home Agent" Functionality?

From: "James Kempf" <[email-masked]>
Date: Thu, 14 Mar 2002 15:15:57 -0800

I'm reading through Section 10.10 in the MIPv6 spec, and there is a
description how to establish forwarding from previous care of address by
sending a BU to a "home agent on the previous link". In Section 10.5, it
describes how an AR advertises a global unicast address for use as a
local "home agent." I'm wondering about the security implications of
this.

One of the nice security aspects of IPv6 router discovery is that the
hosts don't learn anything other than a link local address for the
routers. This helps prevent attackers from outside the local network
hacking into routers. I would expect that a router might have a site
local address for network management purposes, but a global address? And
is it such a good idea to expose that address to hosts? Do people think
this option will be widely deployed?

Also, given that it is deployed, what should the security requirements
be on sending a BU to this local "home agent"? Should they be the same
as for a CN, namely default RR and something stronger when we figure out
what? Or as for sending a BU to the home network home agent, namely
based on an IPsec SA?

I haven't seen any discussion of this, so maybe it isn't particularly
important, but it struck me as curious.

            jak

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 15 Mar 2002 16:29:12 +0100 (CET)

> this option will be widely deployed?

The MIPv6 specification has a mechanism (the 'R' bit in prefix options for
router advertisements) that allow for home agent discovery to work as well as
this HA for a previous CoA to work. That has the effect of providing global as
well as site-local addresses of the router to the nodes on the link.

I don't think security of the routers should depend on their global addresses
being 'secret'. Traceroute would presumably return them in any case.

The benefits of creating a binding for a previous CoA is a function of
the time it takes to do this update - the goal is to prevent packets that
are in transit from CNs (and perhaps MN) from being dropped on the previous
link. Perhaps this is better done using other local mechanisms to minimize
packet drops during handoff?

> what? Or as for sending a BU to the home network home agent, namely

The security requirements for the HA result in the assumption that the MN
has a pre-configured arrangement with its HA in order to associate
the authorization to do bindings for the HoA with an IPsec SA. 
If this is applied to the HA for the previous CoA it would seem to
require some form of pre-establishment there as well.
But that wouldn't introduce any new security concerns and not require
additional specification work.

Doing RR after the MN has moved away doesn't work. The RR check for the 
HoA i.e. previous CoA in this case would assume that the MN is reachable
at the previous CoA, which it isn't.
So unless this RR check is performed (and "refreshed") before the MN moves
and the RR check for the new CoA is done after the move, can RR be made
to work in this case.
Seems complex.

  Erik

---

From: "James Kempf" <[email-masked]>
Date: Fri, 15 Mar 2002 11:57:29 -0800

Erik,

> being 'secret'. Traceroute would presumably return them in any case.

OK. But I assume traceroute would show a site local or link local
address if the router only had that, right? So an attacker wouldn't be
able to hack into it even if they knew it was there, unless they could
break through the site local address routing. And I agree that keeping
the router's address "secret" is not sufficient for security, but it is
like making the TTL 255 on ND traffic, a quick and easy way to eliminate
one class of problems, don't you think?

> packet drops during handoff?

Actually, I think so. This is precisely what the fast handoff proposals
do. The problem with forwarding from previous care of address is that it
is reactive and requires the MN to have a care of address. By the time
the MN has obtained a care of address, many packets may have been
dropped (note that other reactive proposals not requiring the MN to
obtain a care of address may not have this problem). The proactive
approaches in the FMIPv6 draft do better, because they allow the tunnel
to be set up as soon as the MN moves from the old AR.

Not sure whether this is a reason to drop forwarding from previous care
of address, it may have other advantages, if the security implications
can be fully worked out.

> additional specification work.

But shouldn't this at least be stated in the MIPv6 spec somewhere?

> and the RR check for the new CoA is done after the move, can RR be
made

Agree.

            jak