Re: [IPsec] Status of draft-ietf-ipsecme-ddos-protection

"Valery Smyslov" <svanru@gmail.com> Tue, 31 May 2016 06:04 UTC

Return-Path: <svanru@gmail.com>
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 0AA6612D637 for <ipsec@ietfa.amsl.com>; Mon, 30 May 2016 23:04:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.491
X-Spam-Level:
X-Spam-Status: No, score=-1.491 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 pzoacSJ8XLY1 for <ipsec@ietfa.amsl.com>; Mon, 30 May 2016 23:04:46 -0700 (PDT)
Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (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 5219612D660 for <ipsec@ietf.org>; Mon, 30 May 2016 23:04:45 -0700 (PDT)
Received: by mail-lf0-x232.google.com with SMTP id s64so59065275lfe.0 for <ipsec@ietf.org>; Mon, 30 May 2016 23:04:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-transfer-encoding; bh=8eHn67QxA07GbeDsVPUVzY3X4WsCaxIFDoZm5DnXdxc=; b=Ga3PUKnycMYL2nCl1s/6K3rxWlQyKjEUpGGl5+XjSN51d7Ge0222f/eKZS6y/vzNlA BV8DhdbyAJAm4xhryqKJG7GdsJMO7fOp9B8WoNqDLLTRS84as/hjO4Ac3V0Iyr4KThrG ithm7AjGs1eo/aGfITEE5Ci31K2YCcaDLZ9rlVM7bjgoWDB4VuYA1mxj5eL0DqDW5aR7 raxxdfIoZCSI26BPZd8wWsFe56QNbqibO15Cc29jzqnR0aVMS0ITXDQ/3yB3DovokyN4 rnchF22o/C/nBl4vE07e0cBW4EUXi6/C9hj+zAkPvRzPXe/uOHoBwLUf2P2//uMfoQ0H JUiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=8eHn67QxA07GbeDsVPUVzY3X4WsCaxIFDoZm5DnXdxc=; b=PprgZ3eCLEZ61IHdlj44EJZwC+tcCqjEGQ+IAClNdKXTN8DautGyT9XT6rHqeT2432 5fU9QM1o6iteDZhTF3Bapx4XHJhMg8yUAAtaOLrPy7i5ieGLC8drRUXJ8X+JaRefD54f g6Jq5SxbKLXtn832QyqbZyhFIHVC6ZNwyIJsXh+WfPFfUnH0a0LRzSX55lpCBcVBoyHO PR7a+NwdHJASGn4tSdK+8fjDDB4h3njeGsW1UTmW+Nfb1VD8k3hbR4SbUhy9LdPZasZX nveahkoIgM9VnsRw1daRZQFfchV4suA5fclUmI7O5uEAQ0JhpKIQWtUCzILhhqyzVH2g x3eg==
X-Gm-Message-State: ALyK8tL95ebg84iMGnyRe1qtwmkKPCxquWDmD8EqiuWCW/1dtNXXu/2l35Vz26uQrk6rEw==
X-Received: by 10.46.5.143 with SMTP id 137mr6983233ljf.7.1464674683108; Mon, 30 May 2016 23:04:43 -0700 (PDT)
Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id m8sm5153483lfe.15.2016.05.30.23.04.42 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 May 2016 23:04:42 -0700 (PDT)
Message-ID: <CDE9E49B6A0C46C6BCA85D1450779D88@buildpc>
From: Valery Smyslov <svanru@gmail.com>
To: Yoav Nir <ynir.ietf@gmail.com>
References: <860C938B60E24C76A1749A1563D53A55@buildpc> <alpine.LRH.2.20.1605301312210.8086@bofh.nohats.ca> <C2083AF9EC484C129737FE456527D2F4@buildpc> <6ECFA010-549C-45DF-9D88-3D916D706A0D@gmail.com>
Date: Tue, 31 May 2016 09:04:37 +0300
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="UTF-8"; reply-type="original"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipsec/3rGtrSw0CBQ7XE_h-BbHYb5t1QY>
Cc: ipsec@ietf.org, Paul Wouters <paul@nohats.ca>
Subject: Re: [IPsec] Status of draft-ietf-ipsecme-ddos-protection
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 31 May 2016 06:04:48 -0000

>> The concern is not about stand-alone puzzles document. It is about an Experimental status
>> of that document versus Standards Track in the current draft. Vendors tend to ignore Experimental RFCs.
>
> The conventional wisdom is that vendors tend to ignore whatever status the IETF assigns to documents and implement 
> whatever meets their goals.

That's true in general. However Experimaental status makes vendors more suspicious that
they will spend resources implementing the protocol and gain little, because most other
vendors will refrane from implementing it. For puzzles to work they must become ubiquitous.

> My preference is to keep it all in one document, and clearly state that the puzzle part of the document is OPTIONAL,
> meaning that you can comply with the RFC even without implementing it.

That's my preference too. In fact, the current draft doesn't mandate to implement
(or even to use) puzzles, so they are already optional.

> There is a concern about an Initiator that does not implement puzzles connecting to a Responder that does.
> Things will work fine until there is a DoS attack and then we’re helping the attacker by denying service
> to the non-implementing Initiator. And that could happen between an Initiator and Responder,
> both of whom can claim compliance with the document. This isn’t great, but separating them into two documents
> does not make the problem go away.

That's true.

> Yoav

Regards,
Valery.