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

Hi,

On Mar 19, 2021, at 12:36 PM, Paul Wouters < <mailto:paul@nohats.ca> paul@nohats.ca> 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.

          My interpretation is: the responder MAY close TCP connection if it doesn't create

          state. In this case the initiator will have to re-create TCP connection. 

          On the other hand, as Tommy pointed out, according to RFC 7296 the responder

          may keep state in this situation, in which case it won't close

          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.

          Well, it was meant that TCP itself is a stateful protocol, so if 

          the responder receives SYN packet it does create some (TCP) state,

          which violates stateless nature of cookie. So, even if IKE remains

          stateless, TCP doesn't, and thus it is susceptible to DoS attacks.

          I think some clarifications need to be done.

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.

          I concur.

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.

          Exactly.

          Regards,

          Valery.

Thanks,

Tommy

Paul

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