Hi,
On Mar 19, 2021, at 12:36 PM, Paul Wouters < <mailto:p...@nohats.ca> p...@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
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec