Re: [IPsec] TCP and MOBIKE

[Tero Kivinen <[e-mail]>]

Valery Smyslov writes:
> > If the packet is modified, then responder will see it as an attack, as
> > it is using message-id that where it has already processed and
> > responded to, but the content of the frame is not same. As the content
> > is not same, it will not retransmit its reply, so both ends just stop
> > and finally the connection times out.
>
> Depending on the implementation, the content in this case might
> not be checked, the latest response might just be sent.

Could be, but there are implementations which do the check (or
actually check that the hash of the incoming packet is same, they
might not store the whole original packet). And this is something that
is clearly allowed in the RF7296, as request must be bitwise
identical. 

> There is no point to re-check the content of the replayed
> packet, it's only waste of CPU resources.

You do open yourself of (semi) blind reflection attacks if you do not
check the frame. I.e., someone might send 28 byte empty IKEv2 packets
having correct SPI and message ID, and cause you to resend much larger
result.

If you do check the incoming frame attacker needs to see original
frame, and needs to also send as big packet than original sender sent.

CPU is cheap, transmission of frames is more costly. 

> > >From the RFC7296 section 2.1:
> > 
> >    A retransmission from the initiator MUST be bitwise identical to
> >    the original request. That is, everything starting from the IKE
> >    header (the IKE SA initiator's SPI onwards) must be bitwise
> >    identical; items before it (such as the IP and UDP headers) do not
> >    have to be identical.
> > 
> > That is the reason why mobike for example does the processing so that
> > if it needs to change address during UPDATE_SA_ADDRESSES it will not
> > modify packet it is sending out, it will simply run the process to
> > end, and then redo it again from the start. It needs to do if it ever
> > used more than one address, regardless which of them succeeded. I.e.,
> > if it send UPDATE_SA_ADDRESSES using source IP1 and does not get
> > reply, moves to IP2, does not get reply, moves back IP1, and now do
> > get reply, it still needs to do UPDATE_SA_ADDRESSES again because it
> > did not know which of his frames got to the other end. It could have
> > been that first packet ever reaching responder was sent from IP2, but
> > the reply got lost, and then when initiator resent the packet from
> > IP1, the responder just repeated the reply generated earlier packet
> > from IP2...
> 
> These exchanges (trying out IP1, IP2 etc.) will have different
> Message IDs anyway (*).

No they do not. They have all same Message ID, as you can only send
one frame out at time if using window size 1, so you need to wait for
response for message you sent out before you can modify it and send
another frame out. 

> So the responder won't reply with previously saved response, because
> Message IDs will differ. And the content of NAT_DETECTION_*_IP can
> be recalculated accordingly
> 
> (*)  From RFC 4555:
>    If the request to update the addresses is retransmitted using several
>    different source addresses, a new INFORMATIONAL request MUST be sent.

Yes, this means that we need to start new exchange AFTER the one we
are doing now finished. It does not mean that while we sent frame out
using different source IP addresses used different message IDs.

I.e., the exchange is as follows:

 Initiator                  Responder
 ---------                  ---------
      
 (IP_I1:500 -> IP_R1:500, MID=12I)
         HDR, SK { N(UPDATE_SA_ADDRESSES),
	           N(NAT_DETECTION_SOURCE_IP),
                   N(NAT_DETECTION_DESTINATION_IP) } --> 

 (IP_I1:500 -> IP_R1:500, MID=12I)
         HDR, SK { N(UPDATE_SA_ADDRESSES),
	           N(NAT_DETECTION_SOURCE_IP),
                   N(NAT_DETECTION_DESTINATION_IP)  } --> 

 (IP_I2:500 -> IP_R1:500, MID=12I)
         HDR, SK { N(UPDATE_SA_ADDRESSES),
	           N(NAT_DETECTION_SOURCE_IP),
                   N(NAT_DETECTION_DESTINATION_IP)  } -->

 (IP_I2:500 -> IP_R1:500, MID=12I)
         HDR, SK { N(UPDATE_SA_ADDRESSES),
	           N(NAT_DETECTION_SOURCE_IP),
                   N(NAT_DETECTION_DESTINATION_IP)  } -->

 (IP_I1:500 -> IP_R1:500, MID=12I)
         HDR, SK { N(UPDATE_SA_ADDRESSES),
	           N(NAT_DETECTION_SOURCE_IP),
                   N(NAT_DETECTION_DESTINATION_IP)  } -->

                            <-- (IP_R1:500 -> IP_I1:500, MID=12R)
                                HDR, SK { N(NAT_DETECTION_SOURCE_IP),
                                          N(NAT_DETECTION_DESTINATION_IP) }

Now, the UPDATE_SA_ADDRESSES is done, but as the request used multiple
IP addresses the initiator needs to redo it:

 Initiator                  Responder
 ---------                  ---------
      
 (IP_I1:500 -> IP_R1:500, MID=13I)
         HDR, SK { N(UPDATE_SA_ADDRESSES),
	           N(NAT_DETECTION_SOURCE_IP),
                   N(NAT_DETECTION_DESTINATION_IP)  } -->

                            <-- (IP_R1:500 -> IP_I1:500, MID=13R)
                                HDR, SK { N(NAT_DETECTION_SOURCE_IP),
                                          N(NAT_DETECTION_DESTINATION_IP) }


> Anyway, I agree that the current exchange must be finished off
> (either completed or deemed timed out) before a new one is started
> from (to) a different IP.

It MUST be finished, which is why you use all possible IP address
pairs for that ONE exchange before you decide it failed. If it failed,
you delete the IKE SA, and you cannot start any exchange on different
IP after that for that IKE SA, as there is no longer IKE SA you could
use.

See RFC4621 section 6.2 for more datails. 

> But with TCP we don't change address, we only change transport, so
> the exchange must remain the same when switching from UDP to TCP...
> And this would break some things, like NO_NATS_ALLOWED and
> NAT_DETECTION.

It is exactly same for MOBIKE with UDP. NAT detection, IP addresses
used etc can be wrong after the UPDATE_SA_ADDRESSES, and the initiator
MUST detect thiss possibility, and redo the UPDATE_SA_ADDRESSES so
that they will get fixed. Initiator is responsible to try to fix this
until it gets exchange through in a way there cannot be issues which
frame was acted on in the responder, i.e., it MUST ensure that
initiator and responder stays in sync.

In tcp encapsulation the situation is same. Once we move to TCP, or
from TCP to UDP, that is deteced by the initiator that something
changed during UPDATE_SA_ADDRESSES, so after that exchange finishs
successfully, it needs to redo it using the path it thinks work, and
verify that both ends are in sync. 
-- 
[e-mail]