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

From: Paul Wouters <[email-masked]>
Date: Fri, 19 Mar 2021 15:36:33 -0400 (EDT)

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.

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.

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?

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.

Paul

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 19 Mar 2021 19:55:16 -0700

> On Mar 19, 2021, at 12:36 PM, Paul Wouters <[email-masked]> wrote:
> 
> 
> Hi,
> 

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.

> 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.
> 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.

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Valery Smyslov" <[email-masked]>
Date: Sat, 20 Mar 2021 19:21:36 +0300

Hi,

On Mar 19, 2021, at 12:36 PM, Paul Wouters < <mailto:[email-masked]> [email-masked]> wrote:

Hi,

 If the

          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.

          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.

8229 says:

          I concur.

          Exactly.

          Regards,

          Valery.

Thanks,

Tommy

Paul

_______________________________________________
IPsec mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Wouters <[email-masked]>
Date: Mon, 22 Mar 2021 17:05:28 -0400 (EDT)

> 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.

> 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