Subject: Re: [Mip6] MIPv6 issue (IPsec/IKE interaction)

From: Francis Dupont <[email-masked]>
Date: Mon, 01 Mar 2004 08:04:00 +0100

In your previous mail you wrote:

   We saw an interesting problem occur when we tested MIPv6 with IPsec/IKE:
   when the MN does a L3 move at the start of phase 2 SA negotiation with
   the HA, IKE Quick Mode does not complete.

=> IKE is supposed to recover on timeouts even usually it takes time.

  It may be our problem, it may
   be a spec issue. In any case, it is probably a good MIPv6 interop
   scenario. Please refer to attached packet capture
   "quickModeFailsAfterMove.pcap" which has filtered out everything except
   for the IKE messages.
   
   We saw this issue happen during our testing, because we set the policy
   lifetime (in seconds) to 120 seconds, the phase 1 ISAKMP and phase 2
   IPsec SAs were re-keyed very frequently (every 90 seconds or so). 
   
=> with such aggressive timings you should use very short timeouts too!

   When we tested, we had the MN register with the HA from a foreign link
   (K-bit in BU set to 1), this setup the phase 1 ISAKMP and phase 2 IPsec
   SAs between the MN and HA. Then we had the MN move home. The SAs are
   maintained while the MN is home. Then we had KameCN start a FTP MGET of
   a large file from the MN (MN is FTP server). During this FTP, we had the
   MN move to foreign link. Refer to packet #7 in
   "quickModeFailsAfterMove.pcap", what is happening is that the MN is
   rekeying its phase 2 IPsec SAs (Quick Mode exachange), but it starts
   this *AFTER* it has moved to the foreign link so it is sending these
   from its care-of address 3ffe:ffff::20b:dbff:ffe94:83fc. The HA doesn't
   have any phase 1 ISAKMP SA associated with that care-of address, instead
   it has one associated with the MN's home address 3ffe:aaaa::bbbb (see
   packets #3-5) which was re-keyed while the MN was at home. So, the HA
   doesn't recognize these Quick Mode packets sent by the MN (because it
   hasn't yet received any BU K=1 from the MN); the MN retransmits Quick
   Mode (packets# 8-10) but the HA does not respond. Eventually the MN will
   timeout Quick Mode, and recover by re-keying the phase 1 ISAKMP SA. But,
   this can take a long time (2 minutes or so).
   
=> I can see two problems in your IKE implementation:
 - recovering takes too long time (same order than SA lifetimes)
 - it doesn't detect the address mismatch, i.e., it sees different
   addresses and just drops messages (it should not process them
   blindly but should not simply drop them).

   BTW, we used our own HA-Lite simulator for this testing, because we are
   unaware of any open source MIPv6 HA that supports IPsec/IKE that we can
   use to test against.
   
=> KAME/FreeBSD Mobile IPv6 + racoon can be adapted to HA and they
are open source. IMHO the main issue is the KAME/FreeBSD kernel moves
IPsec SAs and SPDs without a warning to IKE but this can be easily
fixed.

   The BU must be protected using IPsec, so the IKE must complete first
   before it can be sent. It seems that in this scenario the MN should be
   able to use the old phase 2 IPsec SAs it had at home to protect the BU,
   to be able to register with the HA from the foreign link without needing
   to wait for Quick Mode to complete successfully.

=> as this SA pair doesn't move (the initiator selector is the home address)
you should use a long term SA pair and you can use it as soon as it is
established at the first time.

   But, for some reason it
   didn't send the BU to the HA.
   
=> this looks like a bug...

Regards

[email-masked]

_______________________________________________
Mip6 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip6

---

From: "Ed Remmell" <[email-masked]>
Date: Mon, 1 Mar 2004 09:53:44 -0800

Francis -

Thanks for your feedback.

> => with such aggressive timings you should use very short 

We think a 15 second timeout is appropriate for an embedded systems
implementation.

>    blindly but should not simply drop them).

We made a change to have the receiver IKE (HA, in this case) to have it
rekey the phase 1 ISAKMP SAs when it detects the address mismatch.

> IPsec SAs and SPDs without a warning to IKE but this can be easily

Please provide more detail about "can be easily fixed". We would like to
use this configuration in our MIPv6 testbed to test MIPv6 with IKE, if
it isn't too difficult to setup.

Thanks.
- Ed

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.593 / Virus Database: 376 - Release Date: 2/20/2004