Hello

 

In the common case, there is a single IKE_SA_INIT exchange and a single
IKE_AUTH exchange (a total of four messages) to establish the IKE SA and the
first Child SA. In exceptional cases, there may be more than one of each of
these exchanges.

 

                In case a DoS attack is expected on IKEv2, the responder may
fight back using certain defense methods. In DoS attack where the target is
flooded with session initiation (IKE_SA_INIT) requests from a spoofed IP
address the responder may use cookie negotiation to defend oneself. This
means that the responder does not do anything until it is verified that the
initiator can receive packets at the address from which it claims to be
sending them. This procedure is called IKEv2 negotiation with cookies and is
illustrated in below figure.

      

IK2.JPG

In cookie negotiation messages (1) and (4) constitute IKE_SA_INIT exchange
and messages (2) and (3) constitute cookie exchange that is used to verify
the initiator. Finally, an IKE_AUTH exchange consists of messages (5) and
(6).IKEv2 DoS protection is optional and it allows the responder to respond
to message 1 with a cookie, which the initiator equally has to include in
message 3. IKEv2 cookie negotiation tries to avoid redundant processing
until the existence of the initiator can be determined.

 

In peer to peer network environment, any one peer can act as either
initiator or responder. In this situation, resistance against DoS attack and
identity protection of both the initiator and the responder is crucial as
anyone can be a victim of attacks.

 

In client server environment resistance of client against DoS attack and
protection of identity of the server is not a priority. But protecting the
identity of client and resistance against DoS attack of server is more
vital. On the other hand, in wireless network environment, where the
bandwidth of channel is less and packet loss is more, DoS attack is major
issue because probability of packet loss is more when the channel is
flooded. 

Having several advantages, ikev2 still suffers from some deficiency, such as
DoS attack, replay attack, man-in-the middle attack, when using in different
network environments and connections. One problem is regarding the way it
protects the peers form DoS attack. It has cookies mechanism to protect
against DoS attack. In this case resistance can be obtained by increasing
the number of message in the initial exchange . What is paid to get the
level of protection is increasing two messages to initial exchange. This
forces the new delay to system especially in wireless environment with high
probability of packet loss. Therefore using this method attacker can gain
the success by introducing delay to valid initiator. Therefore in this case
there is no use of cookies negotiation because host would be still under Dos
attack. Cookies negotiation to be protecting the Dos attack also falls short
in case the attack is carried out by multiple sources and each peer reply
correctly to cookie negotiation.

 

It is important to protect the initiator's identity in both client-server
and peer to peer environment.  In original ikev2, only the identity of
responder is protected by both active and passive attacker. It fails to
protect the initiator identity from the active attacker. One of deficiency
of ikev2, which we found in both client server and peer to peer environment,
is when the responder is invalid entity, the initiator knows about the
responder only when responder is authenticating to initiator.  In this case
the initiator is victim of replay attack and all the computation carried out
by initiator would go in vain.  This is also called as CPU based dos attack
and memory based dos attack.

 

Proposed new negotiations 

ik3.JPG

 

Before initial exchange begins initiator looks up to the pre shared secret
with the intended responder and does the hash value on first half of pre
shared secret, nonce of the initiator. Once the responder receives the
request it looks up the correspondence pre shared key in its table and it
takes the nonce form initiator request message then it does a hash value to
authenticate the initiator. After authentication of initiator the responder
calculate the hash value of its own by using first half of the preshared
key, initiator nonce and responder nonce and send the response to initiator
so that ikev2 can avoid the replay attack, because only the intended user,
who has pre shared key, can only generate hash value. After the IKE_SA_INIT
exchange that is initial  authentication is successful, both the parties
calculates the quantity called SKEYSEED from nonce, second half part  of the
pre shared key and the Diffie-Hellman shared secret established. SKEYSEED
also used to calculate the seven other keys to protect the further messages.

SKEYSEED = PRF (Ni | Nr | second half of PSK, gIR).

 

In case a DoS attack is expected on IKEv2, the responder may fight back
using our advanced cookie negotiation method  which ensure responder  does
no to do anything until it is verified that the initiator can receive the
packets at the address from which it is claims to be sending them. Upon
receiving cookies request message the initiator calculates hash value on
received cookie, first half of the preshared key and nonce of the initiator
to authenticate to responder. Generating the hash value of preshared key
with responder cookie ensure that only intended initiator can replay for the
cookie request. If the cookie negotiation fails, protocol will halt.

 

 

Kindly share the views on the same,

 

Best Regards ,

Ram