Subject: [Ipsec] MIPv6 bootstrapping and IKEv2

From: Francis Dupont <[email-masked]>
Date: Wed, 09 Nov 2005 18:28:27 +0100

This message could be dropped by some mailing-list relays, at least
I've received no comment (including negative :-) at all...

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

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 9 Nov 2005 20:32:18 +0200

> Is there a problem I couldn't see? Is it a good/bad/don't-care idea?

Hmm... so this means that exchange goes like this:

Initiator			Responder
=========			==========

Initiator sends IKE_INIT_SA to
anycast address.

(IP_I:500 -> ANYCAST:500)
HDR(A, 0), SAi1, KEi, Ni  -->

				The packet is delivered to the best
				server servicing that anycast address.

				Server replies using his own IP, not
				anycast address, this is modification
				to the normal MUST processing of the
				IKEv2 in section 2.11. On the other
				hand this can also be considered as if
				there was NAT in front of the
				Responder who NAT'ed the ANYCAST:500
				to IP_R:500 before the packet appeared
				to the IKE server, so IKE actually did
				see packet having (IP_I:500 ->
				IP_R:500), not (IP_I:500 ->
				ANYCAST:500).

			   <--	(IP_R:500, IP_I:500)
				HDR(A, 0) N(COOKIE)

Initiator needs to process
that reply, even when it is
coming from different IP-address
to where it was sent. This should
not cause problems, as it did
know that it sent it to anycast
address, and can enable
special handling for that.

It notices it is N(COOKIE)
and retries, but now it MUST
use the IP_R:500 from the return
packet not the ANYCAST:500
as it did on the first packet:

(IP_I:500 -> IP_R:500)
HDR(A, 0), N(COOKIE), SAi1, KEi, Ni -->

				From this point on the exchange is
				normal IKEv2 exchange.

I think that should work, it do require some changes to the both
server and client, depending how the anycast is done on the operating
system stack. If the anycast server will get the packet in in NAT'ed
form, i.e. where the destination address is already changed from the
ANYCAST to the real IP-address to use (don't know if they do that or
if not), then standard IKEv2 server would work, without any
modifications. If the IKEv2 server gets the anycast address in, then
it needs to replace that with real IP when sending reply.

The client end needs to know that it is initiating to annycast
address, and needs to replace the anycast destination IP-address with
the address from the reply packet. In case there is attacker replying
before the real server replies (or in case the packet goes to multiple
servers because of misconfiguration), the client will probably need to
similar thing than 2.4 3rd last paragraph, i.e. if it receives
multiple replies, it needs to reply to all of them, and once he
manages to get one through the IKE_AUTH it should discard the others.
-- 
[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Mon, 14 Nov 2005 15:35:23 +0100

In your previous mail you wrote:

   Initiator			Responder
   =========			==========

   

=> there is a conflicting MUST about no anycast in a source address.

=> yes, even if the code getting the anycasted message is in IKE itself,
it should be a special case because of the source address of the reply
and possible NAT detection/prohibition.

   			   <--	(IP_R:500, IP_I:500)
   				HDR(A, 0) N(COOKIE)
   
   to where it was sent.

=> it could know it will be the cast (anycast addresses can be recognized,
and this should be the case here).

   This should
   
=> exactly

   (IP_I:500 -> IP_R:500)

=> yes, IMHO it is important to have a minimal change in the IKE code.
   
   system stack.

=> it is done as multicast on reception: you can't bind an anycast address,
you have to bind only the port and get packets to any destination address.

   If the anycast server will get the packet in in NAT'ed
   form, i.e. where the destination address is already changed from the
   ANYCAST to the real IP-address to use (don't know if they do that or
   if not),

=> IMHO the best way is to do that but with an extra level of encapsulation
(i.e., not NAT'ed).

   then standard IKEv2 server would work, without any modifications.

=> as this is simple to do only if a standard IKEv2 server doesn't run
on the same box than the one receiving anycast message, IMHO it is better
to add a small anycast handler in the lower layer reception code.

   If the IKEv2 server gets the anycast address in, then
   it needs to replace that with real IP when sending reply.

=> yes, in the two possible attacks on the initial exchange we already
have the cookie stuff for the receiver side (so we can publish the
anycast address without trouble, one of the ideas behind the HA assignment
is to not offer the Home Agents as victims for DoS), the initiator side
should be done as specified for standard IKEv2...
BTW my concern is to introduce no new possible security concern, it seems
we agree it is the case, i.e., I can write down the proposal in an I-D.

Thanks