[DNSOP] 5011-security-considerations and the safetyMargin
Wes Hardaker <wjhns1@hardakers.net> Wed, 15 November 2017 01:51 UTC
Return-Path: <wjhns1@hardakers.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A13128AFE for <dnsop@ietfa.amsl.com>; Tue, 14 Nov 2017 17:51:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
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 ANNbYuPcaglK for <dnsop@ietfa.amsl.com>; Tue, 14 Nov 2017 17:51:55 -0800 (PST)
Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A49D1200CF for <dnsop@ietf.org>; Tue, 14 Nov 2017 17:51:55 -0800 (PST)
Received: from localhost (dhcp-8309.meeting.ietf.org [31.133.131.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 1AA382808D for <dnsop@ietf.org>; Tue, 14 Nov 2017 17:51:53 -0800 (PST)
From: Wes Hardaker <wjhns1@hardakers.net>
To: dnsop@ietf.org
Date: Tue, 14 Nov 2017 17:49:35 -0800
Message-ID: <ybld14kpaz4.fsf@wu.hardakers.net>
User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/otFC67hr4CUox8BkFkwFD6TU9TQ>
Subject: [DNSOP] 5011-security-considerations and the safetyMargin
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Nov 2017 01:51:56 -0000
The discussion has been long with respect to the safetyMargin in the 5011 security considerations document. There hasn't been a huge conclusion and many different ideas have been floated by, and we're now at the point where we need to pick between them. Below, I try to lay out the primary and sub-options available based on discussions so far. Please provide your opinions on your preference so I can wrap up this draft. Background: This document is not intended to provide operational guidance on what you SHOULD do. It's intended to draw the timing line below which you MUST NOT venture. The safetyMargin was introduced to prevent race conditions based on network delays, eg, which can mean that a RFC5011 Resolver operating at the same time as a PEP Publisher making a change at exactly at the minimum addWaitTime or addWallClockTime values would lead to a failure. So the primary question today is "how do we want to deal with this issue of real-world speed-of-light and other issues?". To complicate this a bit further, packets are never guaranteed to be delivered and network losses can entirely prevent a 5011 Resolver from succeeding at all for a given operation. Option 1. Include a safetyMargin of some value. 1A) safetyMargin = MAX(2*TTL, 1.5Hr) -- current draft 1B) safetyMargin = something based on the retryTime, (an example solution was suggested by MSJ) 1C) Your value here Option 2. Don't include a safetyMargin 2A) Just ignore the issues entirely 2B) Explain that this document does not cover operational complexities like retries (already in the -07 version), network delays and other operational issues. After thinking about this for far far too long, I've now switched my own opinion to that of 2C for the principal reason that this is the line-in-the-sand document, and to be honest people should be using values much larger than this, per MSJ's guidance on how 5011 should be used. Thus, it makes more sense to define this as the "MUST NOT go below this line" without trying to be precise about a value that can never be perfectly accurate, by definition. But, forget my opinion. What's yours? If nothing else, pick one of the [12][ABC] options above please, even without any text defining why you think so (until someone pokes you). -- Wes Hardaker USC/ISI
- [DNSOP] 5011-security-considerations and the safe… Wes Hardaker
- Re: [DNSOP] 5011-security-considerations and the … Wes Hardaker
- Re: [DNSOP] 5011-security-considerations and the … Matthijs Mekking
- Re: [DNSOP] 5011-security-considerations and the … Bob Harold
- Re: [DNSOP] 5011-security-considerations and the … Michael StJohns
- Re: [DNSOP] 5011-security-considerations and the … Wes Hardaker
- Re: [DNSOP] 5011-security-considerations and the … Michael StJohns
- Re: [DNSOP] 5011-security-considerations and the … Michael StJohns
- Re: [DNSOP] 5011-security-considerations and the … Wes Hardaker