On Fri, 19 Mar 2021, Tommy Pauly wrote:

This implies that the new IKE_SA_INIT is a retry of the same IKE SA. Indeed, at 
least for our client, we don’t reset the SA values.

Yes, for a client sure. But for a server there is no guarantee the
client will come back. There is no point in keeping any state, until
now TCP came along.

      Similarly, when IKE_AUTH fails with NO_PROPOSAL_CHOSEN or
      AUTHENTICATION_FAILED, who is responsible for closing the TCP socket?
      The initiator or the responder?


8229 says:

   In order to close an IKE session, either the Initiator or Responder
   SHOULD gracefully tear down IKE SAs with DELETE payloads.  Once the
   SA has been deleted, the TCP Originator SHOULD close the TCP
   connection if it does not intend to use the connection for another
   IKE session to the TCP Responder.  If the connection is left idle and
   the TCP Responder needs to clean up resources, the TCP Responder MAY
   close the TCP connection.

This generally means: client goes first when closing TCP, but server should 
close if the client doesn’t in time.

That makes sense, but again it is different for the server case.
Normally, the server can delete all state after a NO_PROPOSAL_CHOSEN or
AUTHENTICATION_FAILED in IKE_AUTH, as there is no way to fix this failed
IKE SA negotiation - the client has to start from scratch.

Note also that a new TCP connection can always be used for an IKE SA from an 
old connection; that is allowed, so it’s possible that if
the server closes too early, the client will reopen with a new connection to 
send remaining messages.

Right. I guess we need to look at moving our TCP connections without
state into a separate corner, and either close them after a short while
or pick up a new IKE message on it from scratch.

But perhaps this is a useful clarification of the draft. That the
responder has to deal with a TCP session that has no IKE state.

In our case, this ended up in a crasher we are fixing :)

Paul

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to