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

[Bob Harold <[e-mail]>]

On Thu, Nov 16, 2017 at 8:33 AM, Matthijs Mekking <[e-mail]>
wrote:

> 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).
>>
>>
I prefer 1A since the reasoning is well documented.
or  MAX(1A,1B), but that is more complex for little gain.

-- 
Bob Harold