> > 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.
It's much easier to rate limit responses, say no more than one per second.
You may also check the length.
> CPU is cheap, transmission of frames is more costly.
True, but still doesn't justify wasting CPU.
> > (*) 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) }
OK, that only justifies my thought that MOBIKE is fragile :-)
What if both paths work, but the networks are lossy?
In this case with high probability your second exchange
will look like the first: you won't get reply on IP_R1,
switch to IP_R2, got reply and initiate new exchange again.
And so on. The process won't converge well.
> > 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.
OK.
> > 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.
Not exactly. The MOBIKE currently is only concerned with IP addresses.
It doesn't take transport into consideration. If you formally follow MOBIKE
you don't need to initiate new exchange, because when you switch from
UDP to TCP the IP will remain the same.
> 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.
Again, the path doesn't change, the transport changes.
So, this must be clarified in the draft...
> --
> kivi...@iki.fi
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
