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

From: khan wadood <[email-masked]>
Date: Tue, 24 Aug 2004 09:12:41 +0100 (BST)

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

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: "Yoav Nir" <[email-masked]>
Date: Tue, 24 Aug 2004 12:45:12 +0300

In your proposal, the message in packet #3 is encrypted.  If Responder does
not keep any state, it won't be able to decrypt this message.  Add to that
the fact that after message #2 Responder already did the heavy lifting (the
DH calculation), you get no benefit.
 
The point of the stateless cookie is that with very simple calculations and
no kept state, the Responder can verify that the Initiator can get packets

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
khan wadood
Sent: Tuesday, August 24, 2004 11:13 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: [Ipsec] Saving of one exchange in case of DOS attack

 <snip>

QUESTION:

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:

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

  -----------              p;
-----------

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

                                                                 <--
HDR(A,B), SK {IDr, [CERT,] AUTH,

                                                                SAr2, TSi,
TSr}

Where:

 A = Initiator's  SPI

 B = Responder's SPI

Thanks in advance.

wadood