Re: [IPsec] rfc8229bis missing advise on error handling in IKE_INIT

[Tommy Pauly <[e-mail]>]

> On Mar 19, 2021, at 12:36 PM, Paul Wouters <[e-mail]> wrote:
> 
> 
> Hi,
> 
> We have implemented TCP but are running in some issues where the RFC and
> the bis draft does not give us clarify.
> 
> If the IKE_INIT over TCP gets back an INVALID_KE, what is supposed to
> happen? Is the responder expected to close the TCP session, since it
> never created a state for this exchange? Is the initiator expected
> to re-use the TCP connection to send a fresh new IKE_INIT request
> with the proper KE ? This case is similar to the COOKIE case, but
> there the initiator is expected to keep state and re-use, except
> one is not supposed to trigger COOKIES on TCP.

My interpretation here, and the way our client works, is that the connection may be reused.

From 7296:

 If the
   initiator guesses wrong, the responder will respond with a Notify
   payload of type INVALID_KE_PAYLOAD indicating the selected group.  In
   this case, the initiator MUST retry the IKE_SA_INIT with the
   corrected Diffie-Hellman group.

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.

If that is the interpretation of the retry after INVALID_KE_PAYLOAD, it doesn’t violate 8229:

   Multiple IKE SAs MUST NOT share a single TCP connection, unless one
   is a rekey of an existing IKE SA, in which case there will
   temporarily be two IKE SAs on the same TCP connection.

> 
> Note I think this sentence is incorrect:
> 
> 	Moreover, a TCP Responder creates state once a SYN packet is received
> 
> libreswan listens on the TCP socket, but for INVALID_KE responses it
> creates a response without creating a state.

This sounds like a good clarification to make. We can say that it may create state at that point.
> 
> 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.

> 
> Perhaps a similar issue happens when an IKE lifetime is reached before
> a rekey or re-auth happened. But in that case I guess the party sending
> the delete can linger briefly for the reply and then close the socket
> if it didn't get closed by the responder to the delete request.

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.

Thanks,
Tommy
> 
> Paul
> 
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec