Re: [IPsec] New I-D on IKEv3

"Dan Harkins" <dharkins@lounge.org> Thu, 08 November 2012 19:48 UTC

Return-Path: <dharkins@lounge.org>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F4221F8808 for <ipsec@ietfa.amsl.com>; Thu, 8 Nov 2012 11:48:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.265
X-Spam-Level:
X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhMVZIciYlhg for <ipsec@ietfa.amsl.com>; Thu, 8 Nov 2012 11:48:16 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 2AAE221F88B4 for <ipsec@ietf.org>; Thu, 8 Nov 2012 11:48:16 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 6771510224052; Thu, 8 Nov 2012 11:48:07 -0800 (PST)
Received: from 130.129.17.156 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 8 Nov 2012 11:48:07 -0800 (PST)
Message-ID: <453f42808bfd8886e24f71c7f9c38c04.squirrel@www.trepanning.net>
In-Reply-To: <A54B0FE93E854AA4986FD1D680229B20@buildpc>
References: <4f4e246af91b6850545df86389648eb3.squirrel@www.trepanning.net><A7B6EAC4D6AB72429A40150B981E562B0A9E4D@xmb-rcd-x10.cisco.com><c5d806395e00a897a2a711868a1cba3d.squirrel@www.trepanning.net> <A7B6EAC4D6AB72429A40150B981E562B0AA1EA@xmb-rcd-x10.cisco.com> <A54B0FE93E854AA4986FD1D680229B20@buildpc>
Date: Thu, 08 Nov 2012 11:48:07 -0800
From: Dan Harkins <dharkins@lounge.org>
To: Valery Smyslov <svanru@gmail.com>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: ipsec@ietf.org, Dan Harkins <dharkins@lounge.org>
Subject: Re: [IPsec] New I-D on IKEv3
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Nov 2012 19:48:17 -0000

  Hi Valery,

On Wed, November 7, 2012 10:18 pm, Valery Smyslov wrote:
> 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.

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

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

  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.

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

  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.