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

"Valery Smyslov" <svanru@gmail.com> Thu, 30 June 2016 08:52 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 AB4F312B032 for <ipsec@ietfa.amsl.com>; Thu, 30 Jun 2016 01:52:13 -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 v2yGeGs3cdry for <ipsec@ietfa.amsl.com>; Thu, 30 Jun 2016 01:52:11 -0700 (PDT)
Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 0887212B078 for <ipsec@ietf.org>; Thu, 30 Jun 2016 01:52:10 -0700 (PDT)
Received: by mail-lf0-x236.google.com with SMTP id q132so50489922lfe.3 for <ipsec@ietf.org>; Thu, 30 Jun 2016 01:52:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-transfer-encoding; bh=xk3GCBhZqxD0BWHmJ7zIUFIaWNMZU8sbnqMPrpkP/4I=; b=i1h4l0xnLJPpxBGxvjC8FdEXE5YIBI/vb/kNyM1rrXqMvorO/91Hc3OTNnzmoNXuHB caeHz1aPwrBlIPkpReBk2wsDI7+N1pD+Wj+D0QuTReiKvVYVZE2PxKz1qeS1OIxOWpNY Pi08WDTnGrLe4DPrLRiR1doILiSuynISYv4q08hFzKWan027R1dNagfriBhjZ8RctXpy QRkTS2F1c4fT+u8ZwoXk0A5lfqnFvSF4FcDaCLKD95RoJESR6FLHxV5eQ+d6cUGHeeTh paNMuUsAnFemymRxUcQXNcuYcC2zhRUQyC0Dbu6ptHKwCTlkcLni7+6W4v+xducKxxP4 X/Pw==
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:references:subject:date :mime-version:content-transfer-encoding; bh=xk3GCBhZqxD0BWHmJ7zIUFIaWNMZU8sbnqMPrpkP/4I=; b=lSZMc9HJj3ODWOF2AfPtQmzlL5aFQEGYP2r5y06wVHGOOgomW6K1Ga7gVno/6P7oKL UV6x8NaS5nOhjhY6g9A4kq9iQoi3pGjR5E73l+mkwaTvmcjEfTsk36a1LhcAAJTMPuaB WQyf4IOxVKat/XgNF/f90+wOhYorv+M+G25MQ4H1Erod3a6gnRLla3Hgn80qE2Kb/FDU b+7eL6aK+temT0J9e8gO5J0H3kBYFPtUvek0m+FMDidhvpYz3Xqpni4KWtIcHnhunDrR ipfibi6juswHuNqFz2RDunvBp6gPDbDc7f2gwrgBkiYHf+UWVqhNn3uf0vYX1/rYWMEA 4Gnw==
X-Gm-Message-State: ALyK8tKNtnfNBOvtsnHXXhRDQtq3q7hsVqenkhQLkJ2+selCWiQDxh0U58WSoD/6YppLOQ==
X-Received: by 10.25.15.213 with SMTP id 82mr3988534lfp.126.1467276729001; Thu, 30 Jun 2016 01:52:09 -0700 (PDT)
Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id 5sm1323738lja.34.2016.06.30.01.52.07 (version=TLS1 cipher=DES-CBC3-SHA bits=112/168); Thu, 30 Jun 2016 01:52:08 -0700 (PDT)
Message-ID: <33A8023F7A7A4C75A7058E85E6D27A01@buildpc>
From: Valery Smyslov <svanru@gmail.com>
To: "Waltermire, David A. (Fed)" <david.waltermire@nist.gov>, IPsecME WG <ipsec@ietf.org>
References: <DM2PR09MB0665431CCBC1C6B88AE28EA7F0230@DM2PR09MB0665.namprd09.prod.outlook.com>
Date: Thu, 30 Jun 2016 11:52:07 +0300
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
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: <https://mailarchive.ietf.org/arch/msg/ipsec/nQLFvIsiYi1GvWi_RH_MJTjx9Ag>
Subject: Re: [IPsec] Review 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: Thu, 30 Jun 2016 08:52:13 -0000

Hi Dave,

thank you for your review.

>I just completed a review of the DDoS draft. I fixed a number of grammar and wording issues. I would like to issue a 
>pull request, but I don't have access to the site yet. I hope to get that resolved ASAP and then submit the pull 
>request.
>
> While I was reviewing the draft I noticed a couple of small things.
>
> In section 6, the text reads:
>
> When there is no general DDoS attack, it is suggested that no cookie or puzzles be used. At this point the only 
> defensive measure is to monitor the number of half-open SAs, and setting a soft limit per peer IP or prefix. The soft 
> limit can be set to 3-5, and the puzzle difficulty should be set to such a level (number of zero-bits) that all 
> legitimate clients can handle it without degraded user experience.
>
> This paragraph is confusing since the first sentence suggests that no puzzles are used and the last sentence suggests 
> a puzzle difficult value. Should the puzzle text be removed from the last sentence?
>
> How about the following?
>
> When there is no general DDoS attack, it is suggested that no cookie or puzzles be used. At this point the only 
> defensive measure is to monitor the number of half-open SAs, and setting a soft limit per peer IP or prefix. The soft 
> limit can be set to 3-5 to support DoS detection. If puzzles are used, the difficulty should be set to such a level 
> (number of zero-bits) that all legitimate clients can handle it without degraded user experience.

I see your point. I'd rather make a minor change to your text:

        When there is no general DDoS attack, it is suggested that no
        cookie or puzzles be used. At this point the only defensive
        measure is to monitor the number of half-open SAs, and setting a
        soft limit per peer IP or prefix. The soft limit can be set to
        3-5. If the puzzles are used, the puzzle difficulty should be set to such a level
        (number of zero-bits) that all legitimate clients can handle it
        without degraded user experience.

(since Soft Limit is not intended to detect DoS attack).

> Two paragraphs down the text reads:
>
> When cookies are activated for all requests and the attacker is still managing to consume too many resources, the 
> Responder MAY increase the difficulty of puzzles imposed on IKE_SA_INIT requests coming from suspicious 
> nodes/prefixes. It should still be doable by all legitimate peers, but it can degrade experience, for example by 
> taking up to 10 seconds to solve the puzzle.
>
> This assumes that puzzles are already in use, which might not be the case based on the earlier paragraph. Perhaps the 
> following text can be used instead:
>
> When cookies are activated for all requests and the attacker is still managing to consume too many resources, the 
> Responder MAY start to use puzzles for these requests or increase the difficulty of puzzles imposed on IKE_SA_INIT 
> requests coming from suspicious nodes/prefixes. This should still be doable by all legitimate peers, but the use of 
> puzzles at a higher difficulty may degrade the user experience, for example by taking up to 10 seconds to solve the 
> puzzle.

Works for me.

> Section 7.2.1 contains the sentence:
>
> The Responder MUST NOT use puzzles in the IKE_AUTH exchange unless the puzzle has been previously presented and solved 
> in the preceding IKE_SA_INIT exchange."?
>
> Should this state "unless the puzzle" or "unless a puzzle"? It seems like the latter is what was intended.

Sure, the latter was an intended meaning. Thank you.

Regards,
Valery.

> Thanks,
> Dave
>
>
> David Waltermire
> Information Technology Laboratory | Computer Security Division
> National Institute of Standards and Technology
>
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec