Subject: [Mobike] Do we need text about failing RR

From: Tero Kivinen <[email-masked]>
Date: Fri, 28 Oct 2005 16:50:14 +0300

The current document is missing text what happens if the return
routability check fails.

Should we add some text about that?

If there it is genuine attack then we of course want to tear down the
IKE SA (i.e. we do not get any reply back for the RR at all).

The problem is that this might cause IKE SA to teared down even when
there is no attack in case the selected link goes down before the RR
but after the update.

I.e the case is like this:

  Initiator				Responder
  ---------				---------

  Currently using IP_I1 and IP_R1
  for traffic

  Send address update
  (IP_I2:500 -> IP_R1:500)
  HDR, SK { N(UPDATE_SA_ADDRESSES) } -->

					Responder processes the
					request and send ACK.
				    <-- (IP_R1:500 -> IP_I2:500)
					HDR, SK { }

  Initiator updates the IPsec SAs
  to IP_I2, IP_R1.

			Link between IP_I2 and
			IP_R1 breaks down.

					Responder starts DPD
			lost	    <-- (IP_R1:500 -> IP_I2:500)
					HDR, SK { N(COOKIE2) }

			lost	    <-- (IP_R1:500 -> IP_I2:500)
					HDR, SK { N(COOKIE2) }

			lost	    <-- (IP_R1:500 -> IP_I2:500)
					HDR, SK { N(COOKIE2) }

  The inititor will not
  see those return routability
  packets.
					The IPsec traffic is still
					going through from responder
					to initiator, as it uses old
					IP_R1 and IP_I1 addresses
					(they are not yet updated as
					the RR has not finished yet).

				    <-- (IP_R1 -> IP_I1)
					ESP packet

  Data from initiator to the
  responder does not go through
  as he is using new IP addresses

  (IP_I2 -> IP_R1)
  ESP packet -->	lost

				    <-- (IP_R1 -> IP_I1)
					ESP packet

  Initiator will still see packets
  coming from the responder but
  to the old address.

Now the Initiator needs to understand that even if he is getting
packets in, he should start DPD in case those packets are coming from
the different address than where they should be coming. This is not
mentioned in the document now. If initiator does that, this will fix
the situation.

					Responder is still doing RR.
			lost	    <-- (IP_R1:500 -> IP_I2:500)
					HDR, SK { N(COOKIE2) }

  Initiator notices that is not
  getting any trafic to the address
  pair where he is sending traffic,
  and decides to start DPD.

  (IP_I2:500 -> IP_R1:500)
  HDR, SK { } -->	lost

  (IP_I2:500 -> IP_R1:500)
  HDR, SK { } -->	lost

  (IP_I2:500 -> IP_R1:500)
  HDR, SK { } -->	lost

  Initiator notices it is not getting
  data back, thus tries other addresses

  (IP_I1:500 -> IP_R1:500)
  HDR, SK { } --> 
					Responder will get get that
					and reply to it.
				    <-- (IP_R1:500 -> IP_I1:500)
					HDR, SK { }

  Initiator detects that IP_I2,
  IP_R1 address pair is not working
  and switches to the working IP_I1,
  IP_R1 address pair.

  (IP_I1:500 -> IP_R1:500)
  HDR, SK { N(UPDATE_SA_ADDRESSES) } -->

					Responder processes the
					request and send ACK.
				    <-- (IP_R1:500 -> IP_I2:500)
					HDR, SK { }

					Responder retransmits the old
					ongoing RR to the new updated
					address.
				    <-- (IP_R1:500 -> IP_I1:500)
					HDR, SK { N(COOKIE2) }
  Initiator respondeds to RR.
  (IP_I1:500 -> IP_R1:500)
  HDR, SK { N(COOKIE2) } -->
					Responder gets ack to RR, but
					notices that address has
					changed since it was started,
					so he need to restart the RR

				    <-- (IP_R1:500 -> IP_I1:500)
					HDR, SK { N(COOKIE2') }

  Initiator respondeds to new RR.
  (IP_I1:500 -> IP_R1:500)
  HDR, SK { N(COOKIE2') } -->

					Responder is now happy, and
					will update the IPsec SAs to
					the IP_R1, IP_I2 address pair
					(or actually they are already
					there, as it never got them
					changed, but they might have
					moved to some new address).

So we probably want to say something about this, as it do require the
initiator to understand that even when it is getting ESP packets in it
might need to start DPD in case the IP addresses of the ESP packets
are different from what he thinks they should be.
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Fri, 28 Oct 2005 16:54:51 +0300

>are different from what he thinks they should be.
Isn't that already stated somewhere? Seems like its a
part of the NAT behaviour...

Anyway, I believe we do need to say something about
the case that you mentioned. It is indeed possible that
an update fails in any of its stages, including RR. What
I would suggest is that if you don't complete the update
then you continue operating as if it didn't happen, and
be prepared to accept/initiate another address update.

--Jari

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 31 Oct 2005 11:51:48 +0200

> part of the NAT behaviour...

At least it is not mentioned in the NAT-T drafts and I do not think it
is mentioned in the IKEv2 draft either. Protocol draft says:
----------------------------------------------------------------------
   IKEv2 performs Dead Peer Detection (DPD) if there has recently been
   only outgoing traffic on all of the SAs associated with the IKE_SA.
----------------------------------------------------------------------

and that is under NAT-T. IKEv2 draft says:
----------------------------------------------------------------------
   ...     If there has only been outgoing traffic on all of
   the SAs associated with an IKE_SA, it is essential to confirm
   liveness of the other endpoint to avoid black holes. If no
   cryptographically protected messages have been received on an IKE_SA
   or any of its CHILD_SAs recently, the system needs to perform a
   liveness check in order to prevent sending messages to a dead peer.
   Receipt of a fresh cryptographically protected message on an IKE_SA
   or any of its CHILD_SAs assures liveness of the IKE_SA and all of its
   CHILD_SAs. Note that this places requirements on the failure modes of
   an IKE endpoint. An implementation MUST NOT continue sending on any
   SA if some failure prevents it from receiving on all of the
   associated SAs. If CHILD_SAs can fail independently from one another
   without the associated IKE_SA being able to send a delete message,
   then they MUST be negotiated by separate IKE_SAs.
----------------------------------------------------------------------

So that does not say anything about the IP-addresses.

I think we need some paragraph about that to the mobike draft. 

> be prepared to accept/initiate another address update.

The problem in the failing in the RR step is that it is negotiatiation
initiated by the responder, thus it cannot fall back to other
addresses. It is also normal IKEv2 message, which means it must get
reply back or otherwise the whole IKE SA is deleted. So we cannot fail
that RR, we must finish it, and we can only finish it with the help of
initiator noticing that the path does not work, and falling back to
some other path. 
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike