[Ipsec] RE: Saving of one exchange in case of DOS attack

["Charlie Kaufman" <charliek@microsoft.com>]

There was an earlier draft or two of IKEv2 that used an approach similar to the one you suggest. It was part of the IKEv2/JFK merger that the working group subsequently decided to back out. It's not quite as easy as you suggest because message 3 would have to repeat a lot of the information from messages 1 & 2 in order to allow the responder to compute the shared key. Further, those parts of message 3 would have to be sent in cleartext.

The advantage of such a scheme is that it makes the protocol 4 messages instead of the 4 or sometimes 6 of the current exchange.

It was rejected because it required substantial additional complexity at the recipient (always) and made message 3 bigger (always) and only provided a minor performance advantage in the (hopefully rare) case that the recipient is under attack.

	--Charlie

________________________________________
From: khan wadood [mailto:a_wadood_k@yahoo.co.in] 
Sent: Tuesday, August 24, 2004 1:13 AM
To: ipsec@ietf.org
Cc: paul.hoffman@vpnc.org; Charlie Kaufman; ynir@netvision.net.il; kivinen@iki.fi
Subject: Saving of one exchange in case of DOS attack

PREAMBLE:
>From draft-ietf-ipsec-ikev2-15.txt  
   "An expected attack against IKE is state and CPU exhaustion, where the
   target is flooded with session initiation requests from forged IP
   addresses. This attack can be made less effective if an
   implementation of a responder uses minimal CPU and commits no state
   to an SA until it knows the initiator can receive packets at the
   address from which he claims to be sending them."
 
  Initiator                          			Responder
  -----------                        			-----------
       HDR(A,0), SAi1, KEi, Ni   -->

                                 		<-- HDR(A,0), N(COOKIE)

       HDR(A,0), N(COOKIE), SAi1, KEi, Ni   -->

                                 		<-- HDR(A,B), SAr1, KEr, Nr, [CERTREQ]

       HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,]
           AUTH, SAi2, TSi, TSr} -->

                                		 <-- HDR(A,B), SK {IDr, [CERT,] AUTH,
                                             		SAr2, TSi, TSr}

Where:
 A = Initiator's  SPI
 B = Responder's SPI



QUESTION:
My point of view is that why not we do in this way

In this case, Alice will not send her IKE_SPI value to Bob in message#1, instead Bob will send his IKE_SPI value (acts as Cookie) to Alice in message#2. 

Bob will not commit any state until Alice sends her IKE_SPI value and Bob's IKE_SPI value (acts as cookie) to Bob in message#3 (i.e., first message of second exchange).

ADVANTAGES:
1-       We can save cost/time for one extra exchange.
2-       IKE_SPI and Cookie both can be random values, we can get benefit of using Cookie as IKE_SPI or IKE_SPI as Cookie.
  
  Initiator                          			Responder
  -----------                        			-----------
       HDR(0,0), SAi1, KEi, Ni   -->

                                 		<-- HDR(0,B), SAr1, KEr, Nr, [CERTREQ]

       HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,]
           AUTH, SAi2, TSi, TSr} -->

                                		 <-- HDR(A,B), SK {IDr, [CERT,] AUTH,
                                             		SAr2, TSi, TSr}

Where:
 A = Initiator's  SPI
 B = Responder's SPI

 
Any comments will be highly appreciated.

Thanks in advance.

wadood 
 
 

Yahoo! India Matrimony: Find your life partner online.

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec