[IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)
"Stephen Farrell" <stephen.farrell@cs.tcd.ie> Tue, 27 September 2016 17:09 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: ipsec@ietf.org
Delivered-To: ipsec@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C539B12B24D; Tue, 27 Sep 2016 10:09:47 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.34.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147499618776.4465.11672584634820556976.idtracker@ietfa.amsl.com>
Date: Tue, 27 Sep 2016 10:09:47 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/ebgRa0bd8EcmkWt3JeUp9BmO7bA>
Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-ddos-protection@ietf.org, david.waltermire@nist.gov
Subject: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.17
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, 27 Sep 2016 17:09:48 -0000
Stephen Farrell has entered the following ballot position for draft-ietf-ipsecme-ddos-protection-09: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This is a nicely written document... thanks! - I vaguely recalled that puzzles and IPR rang a bell. Did the WG consider [1]? If not, and if it helps, I'm fine with making a 3rd party declaration on that and last call could be done again. Or maybe there's a better way to handle it. Or maybe the WG considered it and are happy enough already that it's not relevant or about to expire or abandoned or something. ("Not relevant" would puzzle me:-) [1] https://datatracker.ietf.org/ipr/417/ - section 3: "if certificates are involved" - you could note here that involving certificates can introduce a network based delay (OCSP, CRLs etc) that's a little different from CPU consumption. (But it's a nit, and you do note a similar issue in 4.7.) - 4.2: "ratelimits should be done based on either the /48 or /64" - would it be better to say "something between a /48 and a /64" maybe? Don't some ISPs assign things in-between? - 4.4: Did you consider making the "4 keys" requirement tied to the PRF algorithm identifier? That would allow for a future where e.g. 6 keys are needed for the same PRF, if that were ever useful. (Without changing current implementations.) I guess you'd need a separate IANA registry that'd initially duplicate stuff in that case so maybe not worth doing. (And could be done later.) - 7.1.1 - you don't clearly say if the cookie value here can be a new one or should be the same as one previously used (if one was previously used). That may just be my ignorance of IPsec cookies though, but I wondered if there are any cases where the initiator gets to work away on the puzzle ahead of time if the same cookie is used for multiple interactions. There's not much (or zero) of an improvement to the attack here, though maybe the attacker could more easily offload puzzle solving to someone else in that case?
- [IPsec] Stephen Farrell's Yes on draft-ietf-ipsec… Stephen Farrell
- Re: [IPsec] Stephen Farrell's Yes on draft-ietf-i… Valery Smyslov
- Re: [IPsec] Stephen Farrell's Yes on draft-ietf-i… Yoav Nir
- Re: [IPsec] Stephen Farrell's Yes on draft-ietf-i… Stephen Farrell
- Re: [IPsec] Stephen Farrell's Yes on draft-ietf-i… Stephen Farrell