Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12

[Warren Kumari <[e-mail]>]

On Thu, May 17, 2018 at 9:27 AM Joao Damas <[e-mail]> wrote:

>
>
> > On 17 May 2018, at 13:29, Job Snijders <[e-mail]> wrote:
> >
> > On Mon, May 07, 2018 at 07:07:05PM +0000, Job Snijders wrote:
> >> 3/ Section 3 states: "The responses received from queries to resolve
> >> each of these names would allow us to infer a trust key state of the
> >> resolution environment.".
> >> From what I understand, in today's DNS world we can only reasonably
> >> expect to do one query per packet. It is well understood that many
> >> operators use BGP-4 anycasting (ECMP), the likes of dnsdist, and/or
> >> simple UDP loadbalancers. I think it may be good to document that
> >> running 3 queries (in essence 3 independent experiments) may not
> >> generate sufficient data to properly infer the state (or any state) of
> >> the resolution environment. Each query (as part of a single sentinel
> >> data gathering session) may be handled by an entirely different resolver
> >> with different keys, contaminating any lookup in the proposed truth
> >> tables. Section 4 covers a number of cases where the results are
> >> indeterminate. It maybe should be added to Section 4 that the client has
> >> no awareness of how the resolver environment is constructed, and thus
> >> requiring multiple independent queries to infer state has its downsides.
> >
> > Do the authors agree with the above observation?
>
> No, not really, at least in my case. What you are saying is that an
> incoherent system behaves in inconsistent manners (a service exposes itself
> to the outside as a homogeneous system but doesn’t behave that way). In
> that case the problem is not one or more queries, the problem is an
> internally misconfigured system.
> If you are referring to the case when a client has several resolvers that
> I can try, I think what we can do is stress even more is that this measures
> the client’s resolver environment, not aspects of particular resolvers. We
> are after finding out whether a user can get a successful resolution in
> their configure environment.
>
> ​Just so the WG knows, the authors (myself in particular) had some
productive discussions with Job at the RIPE meeting in Marseille.
​
As a reminder, this mechanism is designed to measure the *user* impact of
the KSK roll - this means that querying the first resolver in e.g:
resolve.conf, getting SERVFAIL and then failing over to the second (or
third or n-th) until a response is received is fine, and expected.

The document currently contains:
"This document specifies a mechanism that will allow an end user and third
parties to determine the trusted key state for the root key of the
resolvers that handle that user's DNS queries."
and
"The sentinel test described in this document determines whether a **user's
browser or operating system** looking up the special names that are used in
this protocol would be able to validate using the root KSK indicated by the
special names. The protocol uses the DNS SERVFAIL response code (RCODE 2)
for this purpose because that is the response code that is returned by
resolvers when DNSSEC validation fails. If a browser or operating system
has multiple resolvers configured, and those resolvers have different
properties (for example, one performs DNSSEC validation and one does not),
the sentinel mechanism **might search among the different resolvers**, or
might not, depending on how the browser or operating system is configured.
Note that the sentinel mechanism described here measures a very different
(and likely more useful) metric than RFC8145.  RFC 8145 relies on resolvers
reporting towards the root servers a list of locally cached trust anchors
for the root zone. Those reports can be used to infer how many resolvers
may be impacted by a KSK roll, but not what the user impact of the KSK roll
will be." (emphasis added)
and
"Note that a slew of other issues can also cause SERVFAIL responses, **and
so the sentinel processing may sometimes result in incorrect
conclusions.**" (emphasis added).

An example of a case where an incorrect conclusion could occur is if the
client is using an Anycast recursive resolver (e.g: 8.8.8.8) and some of
the backends of that Anycast network have only the old key, and some have
the new key, and ECMP directs you to different backend. Another exmaple is
if the resolver learns the new key *during* a clients testing. To me these
feel like pathological cases, and are covered by "may sometimes result in
incorrect conclusions".
Does the WG feel that this is sufficient, or would it like additional text?
If so, can you propose some?
W



> Joao
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>


-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf