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

From: Wes Hardaker <[email-masked]>
Date: Tue, 14 Nov 2017 17:49:35 -0800

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

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 14 Nov 2017 21:52:19 -0800

Wes Hardaker <[email-masked]> writes:

> opinion to that of 2C

(errr... that should have been "2B")
-- 
Wes Hardaker
USC/ISI

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 16 Nov 2017 14:33:27 +0100

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

---

From: Bob Harold <[email-masked]>
Date: Fri, 17 Nov 2017 00:27:08 -0500

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

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

-- 
Bob Harold

---

From: Michael StJohns <[email-masked]>
Date: Fri, 17 Nov 2017 08:55:18 +0000

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 <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 20 Nov 2017 08:26:40 -0800

Michael StJohns <[email-masked]> writes:

> 1 something.

I think that the consensus is clearly something like that.  Are you
(MSJ) interested in supplying a suggested final equation for it?

-- 
Wes Hardaker
USC/ISI

---

From: Michael StJohns <[email-masked]>
Date: Mon, 20 Nov 2017 16:29:00 +0000

I’m running the math right now to see what works.  Give me a few days.
Mike

---

From: Michael StJohns <[email-masked]>
Date: Mon, 20 Nov 2017 14:47:48 -0500

> (MSJ) interested in supplying a suggested final equation for it?

Ok - after thinking about it, it turns out to be fairly simple.

1) Initially, ignore the outliers - the servers that are down and will 
be down throughout the entire safety period.  It's probable that most of 
them were down during the original uptake period.

2) Assume a success rate of p per retry.  I'm going to use .01 - or for 
each retry period only 1 of 100 entities completes the last query.

3) Calculate Log.x(M) where M is the number of clients - arbitrarily 
chosen at 10M and where x is (1/(1-p)) - the failure rate (or put 
another way, the proportion of servers still waiting to complete after 
the previous retry interval).  Log.x(M) gives the number of intervals to 
reduce the set of uncompleted servers to 0 assuming normal probability.

That gives you 1603 fast retry intervals.   Setting p and M to different 
values gets you a range of answers:

	Number of Resolvers

		10,000 	100,000 	1,000,000 	10,000,000 	100,000,000
Probability of Success Per Retry Interval 	0.01 	916.4212 	1145.526 
1374.632 	1603.737 	1832.84231
0.05 	179.5623 	224.4528 	269.3434 	314.23397 	359.12454
0.1 	87.41738 	109.2717 	131.1261 	152.98042 	174.834763
0.15 	56.67242 	70.84052 	85.00862 	99.176728 	113.344832
0.25 	32.01569 	40.01961 	48.02354 	56.027459 	64.0313822
0.5 	13.28771 	16.60964 	19.93157 	23.253497 	26.5754248
0.9 	4 	5 	6 	7 	8

(Think of it this way.  Pretend you have 1000 resolvers and each has a 
10% chance of completing in each interval.  After the first interval, 
900 are left.  After the second 810, after the third...729 etc.  
Ignoring rounding you need about 65 retries to get down to < 1 left 
which is Log1.11111(1000).

This doesn't account for the servers who are offline, but see (1) above 
for why its probably safe to ignore them.

So a publisher can pick an M and x (or p) that is their best guess from 
the data they have and calculate:

safetyInterval ::=  Log.x(M) * fastRetryInterval

Or simply make some worst case assumptions (.01 success rate, 10M 
clients) and use a number from the table.

Mike

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 29 Nov 2017 14:15:30 -0800

> Ok - after thinking about it, it turns out to be fairly simple.

Thanks for the math and text.  Based on your text, I've added (back) the
section on safetyMargin.  Can you check the -08 version to see if I
mis-spoke you at all?  Note that I added a few more lines and rounded
all the numbers up, since resolvers won't query in a fraction of an
increment.

-- 
Wes Hardaker
USC/ISI