Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" draft-smyslov-ipsecme-ikev2-null-auth
Paul Wouters <paul@nohats.ca> Fri, 23 January 2015 17:22 UTC
Return-Path: <paul@nohats.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4AF1A1AF9 for <ipsec@ietfa.amsl.com>; Fri, 23 Jan 2015 09:22:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbrWeWfP5PPW for <ipsec@ietfa.amsl.com>; Fri, 23 Jan 2015 09:22:01 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B90511A8857 for <ipsec@ietf.org>; Fri, 23 Jan 2015 09:21:56 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3kTS295WHlz5H9; Fri, 23 Jan 2015 18:21:53 +0100 (CET)
Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=h3g+wIzL; dkim-adsp=pass
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id DGWS_ktZ8BWH; Fri, 23 Jan 2015 18:21:53 +0100 (CET)
Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 23 Jan 2015 18:21:53 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id EFFDC8008E; Fri, 23 Jan 2015 12:21:51 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1422033712; bh=icYwYiT9zLrc8unEqX14uP3ZiB3eXXiVh8tB6TZQqEA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=h3g+wIzLMmofbraHvG53fsRBVgOqn5Koxnwx1XaPMUL95hWbtu1B7HqYpgnaiqwB7 ynNnDjJU8aCIsY4ByzGUDrKc6o7KTsZkJT7R/W+ZO5NW6ofGJyh538jiBBSIa8jEtJ jOMnKG3g5+2I4ZVo5K1jJCDb9PyO+6IL/GXKvIOw=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t0NHLpeh021256; Fri, 23 Jan 2015 12:21:51 -0500
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Fri, 23 Jan 2015 12:21:51 -0500
From: Paul Wouters <paul@nohats.ca>
To: Paul Koning <paul_koning@dell.com>
In-Reply-To: <B8D4358C-E4D8-4B28-876E-D99FCC927302@dell.com>
Message-ID: <alpine.LFD.2.10.1501231208130.9546@bofh.nohats.ca>
References: <5E3BDAA5-B0C8-4004-8FFE-25B91199D7EC@vpnc.org> <D0D61010.3756D%grbartle@cisco.com> <363A367E1CF64C4C98586DC57F1AC987@buildpc> <D0DB345D.37DEF%grbartle@cisco.com> <alpine.LFD.2.10.1501131803240.3286@bofh.nohats.ca> <D0E8103C.38B87%grbartle@cisco.com> <B8D4358C-E4D8-4B28-876E-D99FCC927302@dell.com>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipsec/ccPe8f5hoUoQ1Bt-KASAJugZphM>
Cc: "ipsec@ietf.org WG" <ipsec@ietf.org>, "Graham Bartlett (grbartle)" <grbartle@cisco.com>
Subject: Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" draft-smyslov-ipsecme-ikev2-null-auth
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 23 Jan 2015 17:22:03 -0000
On Fri, 23 Jan 2015, Paul Koning wrote: >> Sorry for the late reply. Hopefully the following is more clear? >> >> When designing systems which will provide connectivity for >> non-authenticated users, the system SHOULD be designed with the capacity >> to support not only the maximum intended number of peers, but also include >> an additional number of sessions which are created due to malicious or >> erroneous behaviour. This safety margin will allow a system to still >> operate safely under load until it is exceeded. > > I understand the sentiment, but this seems like a recommendation that can’t be tested and can’t really be implemented either. The trouble is that the number of malicious sessions is unbounded (and may be quite large in a DOS scenario). > > It might be better simply to point out the limitations of the machinery: because authentication is not provided in this case, the receiving system has no way to distinguish legitimate peers from malicious ones. As a result, a denial of service attack may prevent the intended number of legitimate peers from communicating. Additional session (SA?) capacity may help in such cases. > > My point is that this is definitely going to be a case of throwing some more resources at the problem in the hopes it’s enough, but no way to predict whether it’s good enough. Because of that, “SHOULD” seems inappropriate, and a simple statement of the issue and the limitations of this new protocol is better. There are two cases of overload. A "legitimate" overload by simply having too many (anonymous) clients, and an overload by malicious clients. It is hard to tell the difference without authentication. We could introduce a new notification payload for IKE_INIT that pre-announces the desire for unauthenticated IKE. A server could then reject/drop those connections when the load of legitimate clients gets too high without needing to create more state. If later in the exchange an attempt for authenticated IKE is made, the connection can be dropped as malicious. I'm not sure if this will turn out to be a needed feature to help with the legitimate client overload problem, so I'm tempted to postpone adding this until we have field reports that it could be useful. Currently what we (libreswan) are implementing is counting both halfopen SAs as well as states associated with unauthenticated IKE SA's. The halfopen SA's include _our_ outgoing IKE_INIT requests, as a spoofed source ip packet could have caused our end to initiate an IKE_INIT. Paul
- [IPsec] WG Last Call on "The NULL Authentication … Paul Hoffman
- Re: [IPsec] WG Last Call on "The NULL Authenticat… Paul Wouters
- Re: [IPsec] WG Last Call on "The NULL Authenticat… Paul Hoffman
- Re: [IPsec] WG Last Call on "The NULL Authenticat… Yaron Sheffer
- Re: [IPsec] WG Last Call on "The NULL Authenticat… Paul Wouters
- Re: [IPsec] WG Last Call on "The NULL Authenticat… Yaron Sheffer
- Re: [IPsec] WG Last Call on "The NULL Authenticat… Paul Wouters
- Re: [IPsec] WG Last Call on "The NULL Authenticat… Paul Wouters
- Re: [IPsec] WG Last Call on "The NULL Authenticat… Paul Wouters
- Re: [IPsec] WG Last Call on "The NULL Authenticat… Valery Smyslov
- Re: [IPsec] WG Last Call on "The NULL Authenticat… Tero Kivinen
- Re: [IPsec] WG Last Call on "The NULL Authenticat… Paul Wouters
- Re: [IPsec] WG Last Call on "The NULL Authenticat… Sean Turner
- Re: [IPsec] WG Last Call on "The NULL Authenticat… Graham Bartlett (grbartle)
- Re: [IPsec] WG Last Call on "The NULL Authenticat… Paul Koning
- Re: [IPsec] WG Last Call on "The NULL Authenticat… Paul Wouters
- Re: [IPsec] WG Last Call on "The NULL Authenticat… Yaron Sheffer
- Re: [IPsec] WG Last Call on "The NULL Authenticat… Valery Smyslov
- Re: [IPsec] WG Last Call on "The NULL Authenticat… Yaron Sheffer
- Re: [IPsec] WG Last Call on "The NULL Authenticat… Tero Kivinen
- Re: [IPsec] WG Last Call on "The NULL Authenticat… Paul Wouters
- Re: [IPsec] WG Last Call on "The NULL Authenticat… Yoav Nir