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
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.
IPsec mailing list