Do we need text about failing RR

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 protected]