Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04

Yoav Nir <ynir.ietf@gmail.com> Fri, 04 March 2016 17:33 UTC

Return-Path: <ynir.ietf@gmail.com>
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 4AFB41A1E0E for <ipsec@ietfa.amsl.com>; Fri, 4 Mar 2016 09:33:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 h8Gfg5TpavXK for <ipsec@ietfa.amsl.com>; Fri, 4 Mar 2016 09:32:58 -0800 (PST)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96E321A1E0B for <ipsec@ietf.org>; Fri, 4 Mar 2016 09:32:58 -0800 (PST)
Received: by mail-wm0-x229.google.com with SMTP id l68so866643wml.0 for <ipsec@ietf.org>; Fri, 04 Mar 2016 09:32:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=It9uNJB5QfhaVVHp+RYdlxpCC/TEi5jcmBBHyHGSMqc=; b=FI4THSBqxOMwE8cnE//71s3iR+uV6dhyCKraN7DWw8qGOfooJ0uPPPe8tLmz+NWcsu NjxTD+MS9YqmuJ9s54CxmNLOq9nk2rEEdz+JQKqlhnWUJR+nZs5yGE45hw0OXyJHCohk ZtRHybGqJ0x8oTTI4G2rZn5GeW+8C7qK8TrcDXfqpHDtQOlhJ9w2egCQ0NUWpait+AaJ 87+jp4VEffepGR7lihCifIzPapnW9wuBzHnZeuknUrLBvuhOowTJrMz3mwg/QZOgvneu /6CDmP+LCX1a3jfsrwJbKYFNjPzYOBCZ+w9AfrSeZstlso0+vLkYRLo0++gJgeHUYEd+ R6Fw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=It9uNJB5QfhaVVHp+RYdlxpCC/TEi5jcmBBHyHGSMqc=; b=BUB0MGZskXgdXUflpKiLSMEMStlxWExaIG/TjGeV2KD/areraUxP/XrfBjBANTSRGc 3ac+bOD0o+Pnm3ewxvsMrNPVa2FeVH3Qyp3aH+GJRuWOXLWhywoRRzIM9bBsGe50E+ee MQD830pWf6SYwTTVAmir2G7baRI2kp19DYD/YDFEkATQZ3iXLFY8glKfICvETKDImARW 9qxEQedr9QmltIBgsGtny9aRui5c77HxIYJbNA3L8NgLxa3IrumNy00GZ2cvMekzbSdf D6iT5YteY1mXPeikm4mS1hO3NI4z33ccP4/Px6w2Phihu0GUblj5c++pi1n6Ucehg7mh FRpQ==
X-Gm-Message-State: AD7BkJKdJmi0VOO3o3HL7Z9iULvOeD+9LMvI76V7pYobYuQTb7fniaOdZ/tsoLj9PGzLuA==
X-Received: by 10.28.172.194 with SMTP id v185mr77322wme.21.1457112777113; Fri, 04 Mar 2016 09:32:57 -0800 (PST)
Received: from [192.168.1.13] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id jf6sm4388407wjb.2.2016.03.04.09.32.55 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 04 Mar 2016 09:32:56 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <A9AD397B-49C3-48AA-BB09-E23E907F1194@apple.com>
Date: Fri, 04 Mar 2016 19:32:54 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <EBE443B3-3EE6-47FC-B459-A3C6585AB3F9@gmail.com>
References: <BY1PR09MB03587C3829A33D76ECE8EF1BF0BB0@BY1PR09MB0358.namprd09.prod.outlook.com> <CADnPsE-RfHiRdof82CPokYXXVaEa74ssXw2XQ5v7hYpdFYQ7=Q@mail.gmail.com> <alpine.LFD.2.20.1603041020030.29534@bofh.nohats.ca> <A9AD397B-49C3-48AA-BB09-E23E907F1194@apple.com>
To: Tommy Pauly <tpauly@apple.com>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipsec/arHAo2DHsjh-b60hCCi683ZZjJA>
Cc: "ipsec@ietf.org WG" <ipsec@ietf.org>, Paul Wouters <paul@nohats.ca>, "Waltermire, David A. (Fed)" <david.waltermire@nist.gov>
Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04
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: <https://mailarchive.ietf.org/arch/browse/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, 04 Mar 2016 17:33:00 -0000

> On 4 Mar 2016, at 7:02 PM, Tommy Pauly <tpauly@apple.com> wrote:
> 
> Hello Dave,
> 
> I tend to agree with Paul that I find it unlikely, from an implementor’s standpoint, that many Initiators will choose to implement the puzzle logic, especially ones that are running on mobile devices. It is unlikely that the phones will be able to solve the puzzles quickly enough to beat out botnets, and it would be hard to justify the battery consumption necessary. That being said, the document does a very good job of explaining the problem space, and the other parts of its solution (rate-limiting and suggesting session resumption) make good sense. Perhaps there can be more focus on how a responder can best protect itself if indeed the majority of its clients do not support puzzles?
> 
> One question on section 7.1.2:
> 
> If the received message contains a PUZZLE notification and doesn't
>   contain a COOKIE notification, then this message is malformed because
>   it requests to solve the puzzle, but doesn't provide enough
>   information to do it.  In this case the Initiator SHOULD resend
>   IKE_SA_INIT request.  If this situation repeats several times, then
>   it means that something is wrong and the IKE SA cannot be
>   established.
> 
> I am concerned that the suggestion for the initiator reacting to malformed IKE_SA_INIT packets is to send more traffic to the responder. The responder should not legitimately send a PUZZLE notification without a COOKIE notification, since this would be invalid. If the initiator sees this, it can either assume that (a) the responder’s implementation is out of spec, or (b) some malicious third party is deliberately modifying the unencrypted packet. In the first case, trying to send the IKE_SA_INIT again would be in vain; in the second case, we have provided a way for a third party to cause initiators to send more traffic to the responder, thus providing an attack vector. What are your thoughts on this?

A proper responder would not send a malformed packet. An attacker could send a malformed response immediately after the initiator sends the request. By the time the initiator gets the real responder’s response, it has lost state. 

That is why it is always a good idea (not just in this context) for the initiator to ignore malformed responses until the timeout is reached.

Yoav