[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Mobile IPv6 - IPsec interaction.
In your previous mail you wrote:
> => 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.
=> I disagree about routing header and tunneling because mobility
changes the ultimate destination itself.
> 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.
=> I disagree (I can see a far more static situation than you) but
we don't know what will happen.
Sure, there will be also static addresses like the addresses of
root name servers and many big web and corporate servers.
=> only root name servers must have a static address. Other addresses
will be rather static only because this is easier to manage static
addresses than highly dynamic addresses.
But the majority of clients will use stateless autoconfiguration,
=> stateless autoconfig gives always the same address if:
- the prefix is not renumbered (even if renumbering is possible
with IPv6 I can't see good reasons to renumber more often than
every some months)
- the MAC address (ie. the hardware) is not changed (and if you
swap your Ethernet board every hours statefull autoconfig will
provide a static address to you).
The only case with frequent address changes is for privacy
(ie. draft-ietf-ipngwg-addrconf-privacy-xx.txt) but in this case
you don't want incoming connection or be registered in the DNS too.
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.
=> "for sure" will need IPsec.
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.
=> this will kill the DNS for sure.
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.)
=> I want the address to be as static as possible because to get dynamic
addresses makes incoming connections too hard. Some ISPs use dynamic
IPv4 addresses today because they have not enough addresses, this of course
will be different with IPv6.
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.
=> for some contents it will be important to deliver them to the right place.
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.
=> I believe its administrators will simply reject arbitrary IKE request
(the important thing is not to waste CPU cycles in big number computations :-).
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.
=> for instance use DNSSEC to check the home address or simply reject
IKE phase II or the binding update (I expect to have Web servers rejecting
binding updates because common sessions are short term).
One of these mechanisms could be
checking the reachability of the MN through the claimed home address.
=> this supposes deep changes in IKE on CNs. Perhaps it works but
nobody will buy it.
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.
=> for the sake of Internet integrity a global PKI is needed.
Of course some people will disagree so let us assume the global PKI
issue is solved.
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.
=> phase I will work with signatures and certificates so some kind
of global PKI should be there one day (ASAP :-).
> 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.
=> I disagree, it suggest nothing...
On the other hand, unfortunately I disagree with you in that there would
be no authorization problems.
=> there is no authorization problem from mobility because the MN uses
and will use its current/local care-of address. Of course to have a local
address is not enough to be authorized to do anything, but this is not
a mobility issue (ie. this is more in AAA scope).
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. :-)
=> of course they are some kind of attacks or radius/AAA is only
for accounting (:-). But they are not from mobility, ie. they are
not in the scope of this discussion.
> 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.
=> we agree.
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?
=> we can divide this in two parts:
- authorization to establish SA (AAA problem)
- authorization to use the local HA for temporary forwarding
The simplest answer is to rely on the first part, ie. reject SA
establishment after movement and limit the number of visitors with SA
to a reasonnable level.
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.
=> without access control you cannot use clever management of ressources
(ie. you are limited to basic policies like first-in/first-served with
a hard limit).
> 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.
=> where? The current draft tells nothing.
> => 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.
=> I don't thing this will pay enough for the burden (and I have modified
a IKE in order to support link-local addresses in phases I and II so this
is not just a feeling :-).
Thanks
Francis.Dupont@enst-bretagne.fr
Follow-Ups:
References: