Re: [DNSOP] 5011-security-considerations and the safetyMargin

Matthijs Mekking <> Thu, 16 November 2017 13:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7E2D7129439 for <>; Thu, 16 Nov 2017 05:33:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qdT5plrFgOfh for <>; Thu, 16 Nov 2017 05:33:31 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8B6E0124B18 for <>; Thu, 16 Nov 2017 05:33:31 -0800 (PST)
Received: from ( []) by (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vAGDXUv7022226 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <>; Thu, 16 Nov 2017 13:33:30 GMT
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id vAGDXT11022794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <>; Thu, 16 Nov 2017 13:33:29 GMT
Received: from ( []) by (8.14.4/8.13.8) with ESMTP id vAGDXTRK014690 for <>; Thu, 16 Nov 2017 13:33:29 GMT
Received: from [] (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 16 Nov 2017 05:33:29 -0800
References: <>
From: Matthijs Mekking <>
Message-ID: <>
Date: Thu, 16 Nov 2017 14:33:27 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Source-IP: []
Archived-At: <>
Subject: Re: [DNSOP] 5011-security-considerations and the safetyMargin
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Nov 2017 13:33:33 -0000


My preference is to include safetyMargin and have text to explain it 
exists because of network delays etcetera, and also reference to RFC 
5011's retryTime. So that's some mix of 1B 1C or 2B I guess :)

Best regards,

On 15-11-17 02:49, Wes Hardaker wrote:
> 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).