DNSSEC Roadblock Avoidance
draft-ietf-dnsop-dnssec-roadblock-avoidance-05

[Ballot comment]

Thanks for adding alg 8 in response to my discuss. I think you might
want to do another editing pass just to check that the end result is
fully consistent, e.g. I'm not sure if alg 8 should also be mentioned in
section 1.3. The diff from -04 to -05 might also contain a few other
such things, but I'm in an airport now so better I clear the discuss
and leave such tidying to you.

--- OLD COMMENTs below, I didn't check 'em vs. the latest
version

general, mostly 3.x.y: it'd have been nice to include a
dig command line for each of these tests - that'd save the
non-expert reader some time and allow easy scripting of
most of this BCP.

general: Why not say to include a test with a known, but
not well-known, public key (or DS) to check if anyone on
the path is fibbing? E.g. a tester could remember a few
public keys and check that they've not changed in a new
location.  While that may only catch out a cheating real
parent, did you consider including such a test?

- 3.1.4: How is a "recently defined type" a reasonable
thing to check for in a BCP? Seems odd anyway.

- 6.1: what if there is no user? Why not recommend telling
some network observatory? Aren't there some for DNSSEC?

[Ballot comment]
Here is Eric Vyncke's (pretty knowledgeable security expert) OPS DIR review (you'll see that it's in line with Terry's DISCUSS point):
Based on my operational experience, I have seen multiple DNSSEC packets dropped by firewalls because they try to use EDNS0 rather than fragmenting. Does your I-D also address this issue?

I am a little puzzled by the hand waving "we also assume that the path is clear of "DNS interfering" crap-ware/middle-boxes, like stupid firewalls, proxies, forwarders." (I would avoid the use of "stupid") This restriction does not appear as realistic to me in the current deployment.

In the wave of IPv6 deployment and IPv4 sunset, I would suggest that examples (such as in 3.1.1) uses AAAA RR and not A.

It is a little unclear to me WHEN the host should run those test? At boot time? At every network attach? When it resumes operation after a sleep period? Or a periodic test (such as hourly) ? This could cause a scalability problem in vast WiFi deployment.

I am also a little puzzled by another hand waving "The goal of this document is to tie the above tests and aggregations to avoidance practices; however the document does not specify exactly how to do that." and later "Else return an useful error code" which will make interoperation (API portability) complex.

With a little improvement for some unclear (to me) text, this document could be useful. Especially if either the mitigation part is improved or removed completely.

I hope the above will help to improve a very useful document

[Ballot comment]
- I support Terry's discuss.

- 1.2, 2nd paragraph: Is "full non-support" effectively different from "non-support" in this context?

Do we have reason to expect the github project to be maintained for the life of the RFC?

- 3.1.1 et. al. : Do we have reason to believe the dnssec-tools.org domain will be maintained for the life of the RFC?

- 5:

The first paragraph seems to say that the document does not accomplish it’s goal. Is that really the intent? (And doesn't the document at least do some of that?)

"... we can determine what MUST be done in order..."
Spurious 2119 MUST

"short-circuit any unnecessary fallback attempts.":  Does "short circuit" mean the same as "avoid" in this context?

"problems with the name server MAY manifest": Spurious 2119 "MAY"

- 5.1, "It MAY be possible...": Spurious 2119 "MAY"

-5.1.2: s/real/really

- 6: "A newly established network connection MAY change state...": Spurious 2119 "MAY"

-8: Seems like there could be  more to say about the potential consequences about the “fail or proceed without security” decision in 6 and 6.1.

[Ballot comment]
- Agree with Terry's DISCUSS.

- Sec. 2: The last paragraph here isn't really about "goals" and seems like it belongs more appropriately in Sec 3.

- Sec 6.1: I thought recently gathered data has been pointing to the futility of popping up security warnings (e.g., http://neurosecurity.byu.edu/media/Anderson_et_al._CHI_2015.pdf). Does it really make sense to recommend warning users in a BCP? What are users expected to do as a result? Is there any evidence about the proportion of users who even know what DNSSEC is?

[Ballot comment]
I am agreeing with Terry's DISCUSS.

I think this is a useful document, but it is not entirely clear to me how well content of this document will age with time.

Nits:

In section 5:

  This will increase the likelihood that spit-view unsigned answers are found.

Should spit-view be split-view?

On page 14:
  For a stub resolver, problems with the name server MAY manifest themselves as the following types of error conditions:

This is not an implementation choice, so use of MAY is not appropriate. Change to "can" or the like.

[Ballot discuss]
This should be  a very easy DISCUSS to resolve.

In section 4, the second "Note", I urge you to reconsider using the term "crap-ware", and words "stupid", "crap".. these make this document look and sound very poor for an IETF published document. Knowing the intelligence of the authors I can't see how this was thought of as passable and made it through WGLC irrespective of how we collectively view these devices.

Perhaps such words like "protocol naive" are better placed.

[Ballot comment]
small nits and comments:

Abstract: s/outline potential/outlines potential/

s1.1
  second bullet, perhaps you could just say "not DNSSEC aware" to be parsimonious with words
  third bullet '"middle-boxes" actively'?
  fourth bullet "Network components" ?

  para after the bullets: "s/perform these test/perform these tests/ and I don't mean this to sound snide, but what is a regular Validating Resolver? as opposed to something else? (irregular?)
  last para of s1.1. "not uncommon to get results that are not consistent" suggest "not uncommon to get results that are inconsistent"

s1.2 is https://github.com/ogud/DNSSEC_ALG_Check going to be a fully stable URL?

s1.3 May I suggest moving the 'Notation' section above the background to better arm the reader?
    By saying "actual validating resolver" I presume you mean a standalone daemon listening on port 53?

s2 "This document specifies two sets of tests to perform a comprehensive
  one and a fast one." I think you missed a comma.  And is normative language really needed in the following sentence?

s3, you might like to use a RFC4786 reference for anycast in the first 'Note'

s3.1 second para "SHOULD have the recursive flag", suggest "SHOULD have the Recursion Desired (RD) flag set"

s3.1.1, please use the example domain for such examples, ie example.com, and once you have used it do you really need to repeat it for each 'existing' text until you get to the non-existent tests and so on up to 3.1.14.

And on s3.1.14 Will "alltypes.res.dnssecready.org"  be a stable query point?

s 3.3 Some formatting might help with the DNS query examples here.

[Ballot comment]
This was an entertaining read.

I share Mirja's comments. In addition:

I'm not sure how well ESL readers will understand "crap-ware"/"crap" in this passage ("crap-ware" is probably a reasonable term of art, if it's intelligible enough to readers):

  NOTE: when performing these tests we also assume that the path is
  clear of "DNS interfering" crap-ware/middle-boxes, like stupid
  firewalls, proxies, forwarders.  Presence of such crap can easily
  make the recursive resolver look bad.  It is beyond the scope of the
  document as how to test around the interference.

I'm not sure what "ideally MUST" means, in

  However, querying many zones will
  result in answers greater than 1220 bytes so ideally TCP MUST be
  available.

[Ballot discuss]

Why omit sha256 (in particular Alg = 8) from this?  That
seems like a quite bad plan and *not* a BCP given our
current knowledge of hash functions.

[Ballot comment]

general, mostly 3.x.y: it'd have been nice to include a
dig command line for each of these tests - that'd save the
non-expert reader some time and allow easy scripting of
most of this BCP.

general: Why not say to include a test with a known, but
not well-known, public key (or DS) to check if anyone on
the path is fibbing? E.g. a tester could remember a few
public keys and check that they've not changed in a new
location.  While that may only catch out a cheating real
parent, did you consider including such a test?

- 3.1.4: How is a "recently defined type" a reasonable
thing to check for in a BCP? Seems odd anyway.

- 6.1: what if there is no user? Why not recommend telling
some network observatory? Aren't there some for DNSSEC?

[Ballot comment]
1) Shouldn't/can't section 3.1.13. (UDP size limits) also specify a real test?

2) To follow up with the tsv-art review: To avoid network as well as server overload, would it be useful to provide further guidance, when and how often these tests should be performed?

3) In section 6.1.  (What To Do): maybe also list logging as an option in cases where no user is directly involved but a human might check later.

[Ballot comment]
I think this is a useful document, but it is not entirely clear to me how well content of this document will age with time.

Nits:

In section 5:

  This will increase the likelihood that spit-view unsigned answers are found.

Should spit-view be split-view?

On page 14:
  For a stub resolver, problems with the name server MAY manifest themselves as the following types of error conditions:

This is not an implementation choice, so use of MAY is not appropriate. Change to "can" or the like.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-dnsop-dnssec-roadblock-avoidance-04.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: tjw.ietf@gmail.com, joelja@gmail.com, draft-ietf-dnsop-dnssec-roadblock-avoidance@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (DNSSEC Roadblock Avoidance) to Best Current Practice


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document:
- 'DNSSEC Roadblock Avoidance'
  as Best Current
Practice

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-06-17. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes problems that a DNSSEC aware resolver/
  application might run into within a non-compliant infrastructure.  It
  outline potential detection and mitigation techniques.  The scope of
  the document is to create a shared approach to detect and overcome
  network issues that a DNSSEC software/system may face.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-roadblock-avoidance/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-roadblock-avoidance/ballot/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2716/

1. Summary

Document Shepherd:  Tim Wicinski
Area Director:      Joel Jaggeli

Document Type: Best Current Practice

Explain briefly what the intent of the document is (the document's abstract is usually good for this), and why the working group has chosen the requested publication type (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic).

Summary:

  This document describes problems that a DNSSEC aware resolver or application might run into within a non-compliant infrastructure; outlining potential detection and mitigation techniques.  This document attempts to create a shared approach to detect and overcome    network issues that a DNSSEC deployment may face.

As Document Shepherd, I feel the document is ready for publication and I stand behind the document.

2. Review and Consensus

This document was actively reviewed, though in organized bursts when the authors were available.  The authors were very actively in addressing issues brought up and everything brought up both in meetings and on the mailing list were addressed to satisfaction of the working group.

Also, multiple implementations of the compliance checks were written, including teams not involved with the writing of this draft.  This has shown the working group there is a strong consensus from desire for these checks to be standardized.

- Intellectual Property

    There is one known IPR issue that has been disclosed, and all the authors and working group feel this has little to no bearing on the document itself.

4. Other Points

- There are no downward normative references.

- This document does not change the status of any existing RFCs.

- There are no known formal reviews that are needed for this document.

- The document uses FQDNs from dnssec-failed.org and dnssec-test.org, outside of RFC2606. However, these domains have been registered for the purpose of returning answers for the various tests.

- IANA Considerations

    There are no IANA Considerations for this document.