Valery Smyslov writes: > Changed to: > > If a NAT is detected due to the SHA-1 digests not matching the > expected values, no change should be made for encapsulation of > subsequent IKE or ESP packets, since TCP encapsulation inherently > supports NAT traversal. However, for the transport mode IPsec SAs > implementations need to handle TCP and UDP packet checksum fixup > during decapsulation, as defined for UDP encapsulation in [RFC3948]. > Implementations MAY use the information that a NAT is present to > influence keep-alive timer values.
Looks good to me. > The following text is added: > > If the TCP transport was used for the previous network connection, > old TCP connection SHOULD be closed by the Initiator once MOBIKE > finishes migration to a new connection (either TCP or UDP). That looks ok also. > > > Now the question what does the responder do if the other end was using > > TCP connection and mobike, and then responder gets update to new > > IP-address, but does not receive close to the TCP (for example other > > end might have lost its access to the previous network). > > > > I assume it should close the TCP connection after it has verified that > > other has moved all traffic to the new connection (either UDP or TCP). > > I believe this is already covered by 7.1 and no new text is needed. > In particular: > > A TCP Responder MAY close a TCP connection that it > perceives as idle and extraneous (one previously used for IKE and ESP > messages that has been replaced by a new connection). Yes, that should cover it, so no need to add anything else. > > Also note that as described in the RFC 4555 section 3.5 the mobike > > requires retransmit of all outstanding IKE exchanges after the address > > update, and we should most likely make a note of that here too. > > > > I.e. note that RFC4555 has following sentence: > > ---------------------------------------------------------------------- > > o If there are outstanding IKEv2 requests (requests for which the > > initiator has not yet received a reply), continues retransmitting > > them using the addresses in the IKE_SA (the new addresses). > > ---------------------------------------------------------------------- > > > > This should be done even when moving from TCP to TCP. > > I think this is also already covered by 7.2, second clause > (I slightly changed the text to make it more generic): > > o If a new TCP connection for the IKE SA is established while the > exchange Initiator is waiting for a response, the Initiator MUST > retransmit its request over this connection and continue to wait > for a response. I think that partially covers it (of course there might be multiple request, not just one, as the window size might be larger than one). I was just thinking repeating it here as this situation is much more common with mobike, than just normal case. Also you might need to retransmit the old requests over the new connection before you have space in the window to actually send address update for mobike. So having few words here for mobike case would be useful too. Especially pointing out that this is not specific to the TCP encapsulation, this is generic thing that is done when using mobike regardless whether you use TCP or not.. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
