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

Yoav Nir <ynir.ietf@gmail.com> Tue, 31 May 2016 05:43 UTC

Return-Path: <ynir.ietf@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 20FEB12D136 for <ipsec@ietfa.amsl.com>; Mon, 30 May 2016 22:43:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, SPF_PASS=-0.001] 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 8-CSBqUzpAQE for <ipsec@ietfa.amsl.com>; Mon, 30 May 2016 22:43:52 -0700 (PDT)
Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (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 4D06212D66F for <ipsec@ietf.org>; Mon, 30 May 2016 22:43:46 -0700 (PDT)
Received: by mail-wm0-x242.google.com with SMTP id n129so28961905wmn.1 for <ipsec@ietf.org>; Mon, 30 May 2016 22:43:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=P1Jd6tgZqX0SMRm2BBIRM/vAyz4vY3WCbJNU2py0L6g=; b=RahAXmHf8cV3oAnti5O/Kqs0OunNpZBYPIsnWMnTU33zEL4qa+VP5x+nKdSlpzoOxk xdiAnQXofznST15i86vI6RYMXQWIDe/+NJVgQAXHLRi7Regg+EAtH2QFbD0gXWtRMTxj M9Jl+jihHAsukqn3TuftIqDZywfuGJuZXvYoz7jAFQJ547/5qZImv3hIhT6NtmAHV4sF emXZpjgJusmMFTY0ahwcT8HGhe2jay6fbrSksk9kHTg/5ydVjWcwyMLqV+aPTR9SLPYN /dhBG921C1rVP5g297QDc7EerQHlRUwl0OS1PSYdSLdthCB90cPJLpL+1IhL5n3mzpYU JPJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=P1Jd6tgZqX0SMRm2BBIRM/vAyz4vY3WCbJNU2py0L6g=; b=mSuBXZ24fglcKRPKm2TrtP6nD3Att1+6N3ZVAe34BTtps9PxoXTeJANjNsS3Zf/C7t n9MCd7Bi4IZvTrY+Jja9hkImJsy14YCnUvkhRJywjmTEkkrWffvldDQFrnihhe62NRQN UQEHnvKj/rEaxsLoscDyThqY+svbrGvRlaaiJ+SzPHvUs/XOwAnB6/MdvVqbTTn9I34k WfckNz8k+JFcWoYcO7lSCM0wqVaCSa25Zr4Budl2SnKU9IuQEfjVTKDj4+OqVjdvswqp uV/bCNvamRARjDnNIhjIc9CVIgmJO+2ikRt3iPA9wIoLym+G76usUlu2j7ikeg6e1TJ5 bOIw==
X-Gm-Message-State: ALyK8tLbrR7i8zxsIvOlrsvfe3jEKqdJfOlfDaXGw+s/lDzad8D0epHIYrG0q6bjQ0ni8A==
X-Received: by 10.28.8.17 with SMTP id 17mr633619wmi.67.1464673424881; Mon, 30 May 2016 22:43:44 -0700 (PDT)
Received: from [192.168.137.214] ([95.35.61.129]) by smtp.gmail.com with ESMTPSA id xz3sm22193145wjb.35.2016.05.30.22.43.42 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 30 May 2016 22:43:44 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset="utf-8"
From: Yoav Nir <ynir.ietf@gmail.com>
X-Priority: 3
In-Reply-To: <C2083AF9EC484C129737FE456527D2F4@buildpc>
Date: Tue, 31 May 2016 08:43:47 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <6ECFA010-549C-45DF-9D88-3D916D706A0D@gmail.com>
References: <860C938B60E24C76A1749A1563D53A55@buildpc> <alpine.LRH.2.20.1605301312210.8086@bofh.nohats.ca> <C2083AF9EC484C129737FE456527D2F4@buildpc>
To: Valery Smyslov <svanru@gmail.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipsec/X2GD_936900scHsQzXrBTpdjpqo>
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 05:43:54 -0000

> On 31 May 2016, at 8:01 AM, Valery Smyslov <svanru@gmail.com> wrote:
> 
> Hi Paul,
> 
>>> On the other hand, if we go this way and give the puzzles stuff an Experimantal status, then probably very few vendors (if any) will implement it and the real problem of defending against
>>> (D)DoS attacks will remain unaddressed.
>> I don't think the puzzles implementation adoption will be much different from
>> whether it is part of the ddos document or a stand-alone document.
> 
> 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.

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. 

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.

Yoav