Hi Tero, > > 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.
Makes sense. > > 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. The uselessness of the return routability check in case of TCP is already mentioned in the draft. > > 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. Depending on the implementation, the content in this case might not be checked, the latest response might just be sent. There is no point to re-check the content of the replayed packet, it's only waste of CPU resources. > >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 (*). 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. 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. 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. Regards, Valery. > 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
