[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Mobile IPv6 - IPsec interaction.
[Francis, I am sending this to the list, as well. I wish you
do not get upset. I'd prefer to have this discussion open.]
> (Note that in all of the
> following, the term "MIP6 SA" refers to an IPSEC security
> association that is used to protect MIP6 signalling, i.e.,
> binding updates and acknowledgements.)
>
> => in fact it is a SA pair.
I stand corrected. I agree that if you want to have your
binding updates acknowledged (and you do), you need to have
a pair of IPSEC SAs.
> 1. The security requirements for the MIP6 SA are different
> depending on whether it is used
>
> => security requirements themselves are not different but the context
> where they can be provided is very different.
Well, what I was trying to say, _fundamentally_, is that the
even the security _requirements_ are different, depending on
the party are considering. The different parties have different
interest, and therefore their security requirements are different.
> Now we get to the underlying assumptions, or to the question
> why the authorization is needed in the first place. I agree
> that we do need authorization, but the exact reasons for the
> need seems to be unclear to me.
>
> => mobility signaling is the best impersonating tool you can imagine.
I agree. It is one of the best impersonating tools. Unfortunately,
IPv6 offers you a number of almost equally good alternatives,
including the routing extension header and generic tunneling.
> 1. MN--HA
>
> a) to make sure that whenever I send a packet to a
> particular address, it really goes to the host I
> suppose it is going to
>
> c) to limit resource consumption
>
> => I believe main reasons are points a (impersonate attack) and c (DoS).
I do agree with DoS resistance. However, IMHO, in the IPv6 it will
be _much_ harder to "know" the host a certain address belongs to, at the
given moment fo time, than in the current IPv4 world. As I tried to
argument, it seems like most addresses will no longer be static.
Sure, there will be also static addresses like the addresses of
root name servers and many big web and corporate servers.
But the majority of clients will use stateless autoconfiguration,
and may be using series of different addresses. Thus, if you
have an address, you do not necessarily know for sure whom packets sent
to it will reach.
Thus, I think that we could divide the point a) into two subpoints.
a1) During a certain period, i.e., address lifetime, I want to have
_some_ assurance that the packets sent to a certain address
will be received by the very same host. It seems like a
typical _client_ address lifetime will range from tens of
minutes to a few days. If I want to have _high_level_
assurance that the the same host is all the time receiving
the packets, I need to use IPSEC or SSL anyway.
(Yes, I know, some people strongly disagree with me. They
want the client addresses to be static. But I don't believe
that they ever will.)
a2) Ethernally (or at least for a long time like months or years),
I want _high_level_ assurance that the packets send to a certain
address will be received by the very same host, all the time.
I, personally, would consider these two requirements _very_ different.
Basically, my argument is that we want to have a1), and that it is
practically impossible to provide a2), at least without explicit IPSEC,
anyway. Thus, I would consider the following point of yours to be
covered by requirement a1)....
> => even if you wouldn't care of previous addresses you should like
> to be the only node using your current address, ie. be protected
> against connection thefts (and in this case (MN--HA) one can
> steal many connections).
... thus, I basically agree with you. Fortunately, providing the
requirement a1) does not necessarily need manual configuration.
It is only the other requirements that need manual configuration.
> 2. MN--CN
>
> In the typical MN--CN case, the MN and CN belong to different
> organizations. In that case, the CN does not really care which
> home address (and home agent) the MN claims to use. If it wants
> to do access control, it should base it on IP addresses anyway,
> but on other means (e.g. IPSEC or SSL).
>
> => I disagree, the MN cares that the CN cares (for existing connections
> or for new connections, of course for the second case you'd like
> to mandate DNSSEC too).
Well, let us see. If we assume that the CN is a typical web server,
I cannot imagine how it could possibly care? To the web server, the
important thing is to get the content delivered. I really can't see
how its administrators would be careful enough to configure it to
check that an arbitrary mobile host is really entitled to use a
certain home address. For them, it is the MN's business, anyway.
On the other hand, I can easily imagine that the OS vendors, for the
sake of Internet integrity, would include some default mechanisms
in their IPv6 implementation. One of these mechanisms could be
checking the reachability of the MN through the claimed home address.
For example, when the MN hands over the home address in IKE Phase II,
the CN could reply using the home address (thereby making the
packet to be tunneled by the Home Agent). If the MN indeed gets
the packet, and replies to it, the CN knows that the MN is able
to use receive packets through the home address. I think that something
like this is the best we can ask for without a global PKI.
Thus, the basic distinction here is that a global PKI is hard to
establish, and requires care by the administrators. On the other
hand, a simple home address reachability test can be engineered
into the IPv6 implementations.
> 3. MN--temporary HA
>
> In section 10.9 of the MIP6 draft, a method is specified where a
> MN creates a temporary registration on a HA on the previously
> visited network. The purpose of this registration is to forward
> packets that are sent with the old COA. I think this situation
> is the most interesting one from security point of view.
>
> => this is less interesting if the SA is built before to move, ie
> with the current CoA which will take the home address role
> (phase I & II identities will be the same, no authorization problem).
Right. Creating the SA before the move simplifies things. Thus, maybe
we should rewrite this section of the MIP6 draft? Currently it suggest
that the SA is created only after the move.
On the other hand, unfortunately I disagree with you in that there would
be no authorization problems. Let me think about this for a while, and I am
sure I can come up with some kind of an attack. At least if you allow
globally routable addresses to be used, and if you do not assume a
global PKI, and maybe even if you do assume a global PKI. :-)
> A basic security problem here is someone may want to try to
> create a temporary HA registration just in order to divert
> your traffic. Thus, to me, it seems like the most important
> issue here is to bind the HA registration to the original
> care-of-address assignment. Now, in MIP6 CoA assignment
> may be based on either stateless or statefull (DHCPv6)
> autoconfiguration (MIP6 sec 10.5). Typically, neither of
> these methods provide any security other than requiring
> physical access to the link. Thus, the current standards
> and drafts do not seem to appropriately solve this problem.
>
> => the visited network security is another problem which is
> in the AAA scope.
Well, I think that there are two separate problems. The first one
is the visited network access control problem, i.e., the problem
whether the MN should be given an address in the visited network.
That definitely belongs to the AAA scope. However, I was trying to
clarify a separate problem, that is, given that the MN is allowed
to have an address in the visited network, how does the HA in the
visited network know that the particular MN really was using a
particular address in the visted network, and is actually authorized
to ask for forwarding?
For example, suppose that the visited network has no access control
but instead accepts all MNs. In that case, the simples way is to
use stateless autoconfiguration, without any security, to give an
address to the MN. Now, there really is a problem when and how
the HA in the visited network should allow temporary forwarding.
> One possible direction for seeking for a solution would be
> to create a SA between the MN and the visited network HA
> already _before_ the MN leaves the link.
>
> => of course you should do that!
But, as I said, the current draft tells you to do otherwise.
> => to use link-local addresses will only make things more complex.
Maybe. But they give you an added level of security. You _know_
that the peer is actually connected to the same link.
Yours,
--Pekka Nikander
Follow-Ups: