Subject: Re: [IPsec] New I-D on IKEv3

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 8 Nov 2012 10:18:48 +0400

Hi Dan,

I suspect the IKEv3 in its current form is susceptible to very simple DoS 
attack.
Suppose we have Alice, Bob and Malory. Alice wants to communicate with Bob,
Malory wants to not allow her to do it. For this Malory sends INIT packet to 
Bob
pretending to be Alice (this packet may have fake or real Alice's source 
IP).
Bob's state machine transfers to Reception state and Bob replies back
to what he thinks is Alice. This reply packet either goes to nowhere
(if IP is fake) or get dropped by Alice according to 6.1.1.2 first bullet.
Now Malory has achived his goal - untill TM event happens and
Bob's state machine returns back to Nothing state, Bob will
discard any INIT packet from real Alice according to 6.1.1.2 second bullet.
What Malory needs to do - infrequently send such INIT packets and
Alice will have almost no chance to communicate with Bob.

I think the root of this susceptibility is in the draft's intention to have 
only one
instance of IKEv3 protocol running between two peers, even before
peer is authenticated or, at least, confirmed her ability to
participate in IKEv3 (for example by COOKIE exchange).

Another thing (among others that have been already mentioned by other 
people)
that I think decreases protocol usability - the lack of error notifications.
If something goes wrong (due to misconfiguration, etc.) peers never
report the problem to each other, so protocol will try to retransmit for 
quite
a long time before some recovery actions could be done
(for example switch to another peer).

Regards,
Valery Smyslov.

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 8 Nov 2012 11:48:07 -0800 (PST)

Hi Valery,

> Alice will have almost no chance to communicate with Bob.

  That is a very good point. It makes me want to do away with the
SPI since it really serves no purpose in IKEv3.

> participate in IKEv3 (for example by COOKIE exchange).

  Once the peer is authenticated the SA goes away so there is really
only 1 nascent SA between 2 peers, once it's done it's job it goes away.

> (for example switch to another peer).

  What errors would you like to receive? If you don't like my attribute
assertion do you want to tell me why? I'm sure that can be handled
by sending an error message and going away. What if you fail to
authenticate me? Do you feel compelled to tell me that I failed? What
else would you like to see?

  Thanks for looking at IKEv3 and I hope you will take a look at the -01
version.

  regards,

  Dan.