Tommy Pauly writes: > This MUST should probably be downgraded to a SHOULD, and add > explanation about the reuse case. The point of this text was to make > sure that initiators don’t needlessly leave TCP connections open to > responders, and take up resources on the responder. A better text > would be: > > "In order to close an IKE session, either the initiator or responder > SHOULD gracefully tear down IKE SAs with DELETE payloads. Once all > SAs have been deleted, the initiator of the original connection SHOULD > close the TCP connection if it does not intend to use the connection for > another IKE session to the responder. If the connection is left idle, > and the responder needs to clean up resources, the responder MAY > close the TCP connection."
Much better text, this I can understand and agree... > > Same for the IKE SA, i.e. the message-id must be larger than anything > > seen before, not just something that is in the window. > > I will add text to specify that the IKE and ESP messages must be > valid (pass authentication and decryption), and have higher IDs than > previous messages. Actually Valery did raise good point, that for IKE this might cause issues. Now when I am thinking about this, I think that for IKE packets the response to the IKE request should go to the same TCP session where the request came in. This would be aligned with the RFC7296 which says you reverse ip-addresses and ports for incoming IKE request, and reply to that address. I.e., if you get request 5 in using tcp connection 1, you send your response to connection 1, if you another request 6 coming in using connection 2, you send your response to connection 2. If you then see retransmission of the same request 6 from connection 1, you resend your response to connection 1. I.e., it might be that connection 2 is not working properly, for example return packets do not get through. This kind of things can happen if for example NAT or firewall in the middle is blocking inbound traffic for some ports or something. For new requests the IKE should use the same TCP session than what is being used for ESP, i.e., the most fresh one. The most fresh should then be defined as the one which has received ESP sequence number which is not out of order (note, that there might be multipe ESP SAs in the same TCP connection, so largest sequence number is not right way to express this), or which has received new IKE request (note, not IKE respose, or retrasmitted request) last. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
