[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipsec
Subject:    Re: [IPsec] rfc8229bis missing advise on error handling in IKE_INIT
From:       Paul Wouters <paul () nohats ! ca>
Date:       2021-03-22 21:05:28
Message-ID: 3e6d6be6-7da-c7bc-606a-667bc9fe1c3 () nohats ! ca
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]