Re: [IPsec] TCP and MOBIKE

[Tero Kivinen <[e-mail]>]

Valery Smyslov writes:
> Hmm, maybe. Or maybe not. Or maybe just ignore it in case of TCP?

I would say that is better approach. I.e., ignore NO_NATS_ALLOWED and
NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP o receiver
when connection comes in with TCP.

There is nothing we want to do even if detected NAT on the tcp path,
we are not going to switc to switch to another port, we are not going
to allow dynamic updates (as they would not work with TCP anyways),
there is no point of sending keepalives on TCP etc.

So on tcp just ignore those payloads. 

> I think that in general the co-existence of MOBIKE and TCP must be
> elaborated in more detail in the draft.

I agree. There are also several cases where we some of the mobike
processing does not really make sense. Things like return routability
checks, changing nat mappings, etc. The initial UPDATE_SA_ADDRESSES
should be enough to just say that use this connection for return
traffic. I do not think there is anything else for the responder to do
for it. 
> 
>     request. Probably we could clarify in TCP guidelines draft that the content
>     of NO_NATS_ALLOWED MUST be recalculated in this case? Or is it obvious?

Modifying the packet after it has been sent over any transport once,
is impossible, and will break things.

I.e., if client send packet using UDP and it did reach the destination
correctly, but return packet got lost, and then client decided to move
to TCP, and resend the packet.

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.

>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... 
-- 
[e-mail]