Subject: [Ipsec] MIPv6 bootstrapping and IKEv2

From: Francis Dupont <[email-masked]>
Date: Wed, 26 Oct 2005 00:19:45 +0200

IKEv2 is assumed to become the default mechanism in MIPv6 bootstrapping,
both because the MIPv6 security between a mobile node and its home agent
(HA) is based on IPsec and because IKEv2 is efficient, provides
configuration, support legacy authentication, etc.
Look at draft-ietf-mip6-ikev2-ipsec-04.txt ...

But something IKEv2 doesn't (yet!) know to do is the assignment of
the HA address, mainly because when you are talking with the HA
you already have its address... MIPv6 has some HA address discovery
mechanisms (a problem very similar to the SG discovery) and is looking
for HA (address) assignment mechanisms.

HAs on the same link share an IPv6 anycast address (a group address
like multicast but messages are delivered to one member of the group
and the format is the same than for unicast. IPv6 anycasts share some
properties with multicasts: they must not use as source addresses and
a stream of messages is not required to be delivered to the same node).

A proposal is the initiator (aka mobile node aka VPN client) sends
the first message (IKE_SA_INIT) to the anycast address, the receiving
HA forwards it to the "best" HA which answers using its own unicast
address. The initiator keeps this address as the responder address
for further messages.

IMHO we should enforce Cookie mechanism in this case:
 - we always get a full IKE_SA_INIT exchange using the right addresses
 - we can't mess NAT detection or other things relying on addresses
 - an anycast address is a good target for attacks so to always
   consider it is under attack is just pessimism

Is there a problem I couldn't see? Is it a good/bad/don't-care idea?
(BTW it is not mine)

Regards

[email-masked]

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec