1

This is a question hitting my mind but can not come up with solution. Suppose there is a IKE tunnel between two peers (peer_1,peer_2). Now there is an attacker who wants to break this tunnel. What the attacker is doing is that for every keep alive Informational Request from peer_1 to peer_2, he/she(attacker) replies back with INVALID_IKE_SPI notify payload and obviously this message would be in plain text. This results peer_1 believing the IKE_SA got some problem and after implementation specific retry the peer_1 closes the tunnel(Although rfc 7296 specifies that peer receiving such reply should not change its state but there should be an end of retrying keep alive to get rid of network flood). As a result the attacker wins.

Is there anything IKEv2 Protocol itself says to prevent this type of situation?

If anyone knows about this please reply me back or some solution will be also helpful.

user2940110
  • 69
  • 2
  • 7

1 Answers1

0

Citing RFC 7296, section 2.4, paragraph 3:

Since IKE is designed to operate in spite of DoS attacks from the network, an endpoint MUST NOT conclude that the other endpoint has failed based on any routing information (e.g., ICMP messages) or IKE messages that arrive without cryptographic protection (e.g., Notify messages complaining about unknown SPIs). An endpoint MUST conclude that the other endpoint has failed only when repeated attempts to contact it have gone unanswered for a timeout period or when a cryptographically protected INITIAL_CONTACT notification is received on a different IKE SA to the same authenticated identity. An endpoint should suspect that the other endpoint has failed based on routing information and initiate a request to see whether the other endpoint is alive. To check whether the other side is alive, IKE specifies an empty INFORMATIONAL request that (like all IKE requests) requires an acknowledgement (note that within the context of an IKE SA, an "empty" message consists of an IKE header followed by an Encrypted payload that contains no payloads). If a cryptographically protected (fresh, i.e., not retransmitted) message has been received from the other side recently, unprotected Notify messages MAY be ignored. Implementations MUST limit the rate at which they take actions based on unprotected messages.

I think that (for the sake of clarity) the relevant types of an attacker should be considered:

1/ An attacker able to drop arbitrary packets (i.e. an active MitM)

  • this one is able to perform DOS just by dropping packets and AFAIK there is nothing that can prevent him doing so. He does not need any sophistication to break the communication.

2/ An attacker unable to drop packets

  • this one can not prevent peer_2's legitimate responses (to peer_1's INFORMATIONAL requests) reaching peer_1.

  • thus peer_1 receives the response (before all retries timeout) and knows that peer_2 is alive.

3/ An attacker able to drop some packets

  • then it is a race and the outcome depends on the configuration of the peers and the percentage of packets the attacker is able to drop.

EDIT>

I would understand the questioned "case 2 attacker" scenario this way:

  • by receiving the attacker's unprotected INVALID_IKE_SPI notify (spoofed by the attacker from peer_2's address) peer_1 can (at most) only suspect that peer_2 has failed (as it MUST not conclude that the other endpoint has failed based on IKE massages without cryptographic protection)

  • it may decide (see note below) to issue a liveness check by sending an empty INFORMATIONAL request to peer_2 (which is cryptographically protected)

  • the "case 2 atacker" is unable to tamper with this request, so it should reach peer_2 (it might involve some implementation specific retransmits, as specified)

  • peer_2 (as it is alive) responds with an acknowledgement (which is cryptographically protected)

  • the "case 2 atacker" is unable to tamper with this response, so it should reach peer_1

  • upon receiving this response (which is a fresh, cryptographically protected message from peer_2), peer_1 knows that peer_2 is alive and keeps the SAs (as nothing has happened)

Note: The "Implementations MUST limit the rate at which they take actions based on unprotected messages" part means, that peer_1 should not perform this liveness check on every unprotected Notify message received and some implementation specific rate limiting mechanism must be in place (probably to prevent traffic amplification).

Desclaimer: I am no crypto expert, so please do validate my thoughts.

Community
  • 1
  • 1
vlp
  • 7,811
  • 2
  • 23
  • 51
  • 1> This would led whole network connection down if you are thinking to drop all packet. 2> This(3rd bullet point) is what I was asking. 3> The attacker would not have any guarantee whether he/she would succeed or not. I think from attacker perspective it is not good method. – user2940110 Nov 18 '15 at 04:45
  • @user2940110 Sure, but (given your answer did not specify attacker's capabilities) I tried to cover all the relevant attackers in the answer. – vlp Nov 18 '15 at 09:04
  • @user2940110 You might want to consider accepting the answer to mark it resolved (if you feel so)....Maybe the [first one](http://stackoverflow.com/questions/29799072/ikev2-rekeying-of-ike-sa-using-create-child-sa-message) as well...Good luck with your IPSEC project! – vlp Nov 18 '15 at 09:07
  • sorry for not accepting answer for the [first one](http://stackoverflow.com/questions/29799072/ikev2-rekeying-of-ike-sa-using-create-child-sa-message) , I have already accepted that :P..... For this one, my question was the prevention mechanism of such attacks(i.e. response with INVALID_IKE_SPI), can you think of any such mechanism? – user2940110 Nov 20 '15 at 05:00
  • @user2940110 As I understand it, the mechanism is already there -- tried to edit the answer. – vlp Nov 21 '15 at 14:32