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

[Michael StJohns <[e-mail]>]

1 something.  I also believe it should scale as to the size of the
subscription base in some way.   Basically, this should answer the question
of “ given a set of subscribers of size N, a per request failure rate of f,
a retry time of R, how long do you have to wait until P% of the subscribers
have had a successful query?”

So with P == 99.99%, R being the fast retry time, f being 5%? And N being
10M, it should be possible to calculate how long to wait.  Basically a
cumulative distribution function.  When I get back to my laptop, I’ll check
in with excel and see if I can give you an idea of what this looks like.

That gives you a reasonable lower bounds for the uptake AFTER dealing with
expiring old records and reprents N resolvers doing their last query to
validate the new trust anchor.

I estimated it as a log function time retry time in an earlier email.

Later, mike



On Fri, Nov 17, 2017 at 13:27 Bob Harold <[e-mail]> wrote:

> 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
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>