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

[Matthijs Mekking <[e-mail]>]

Wes,

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,
   Matthijs

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).
>