Brian
While I attempt to corral the authors, let me attempt to answer these
questions as the Document Shepherd.
Answers inline.
On 6/14/16 8:13 AM, Brian Trammell wrote:
Greetings,
I've reviewed this draft as part of the TSV Area Review Team, paying special
attention to transport-related concerns. Please take these as any other IETF
last call comments.
Summary: This draft clearly describes online testing of possible DNSSEC
failures, and how to interpret the results. It does not appear to pose any
transport-related danger, and is broadly ready for publication as a BCP.
I do have the following questions, though:
(1) Section 3.1: "The tests are designed to check for one feature at a time". This is
generally A Good Thing, but it does seem that there should be some attempt to economize on packets
sent. This is not as much a problem when testing recursive resolvers, since they should only need
to be run when a host introduces itself to a neighboring recursive resolver and the test traffic
shouldn't leave the site. However, section 3.2 are designed to run on the open Internet, and seems
to suggests that tests 3.2.1-3.2.3 should be run *first*, then followed by the fourteen tests in
section 3.1. In the "best case" future for this document, that every stub resolver
implements this online testing automatically, every packet saved is significant.
Interesting point, but the tests in 3.1 would never be run against the
servers in section 3.2. I agree, if they did, your optimization would
be useful. I am looking for the text which may imply running section
3.1 tests first before running section 3.2 texts
Some optimizations are obvious: 3.2.1 replaces 3.1.1, 3.2.3 replaces 3.1.2. The
document should note these (even though they're trivial). Some optimizations
have already been made: 3.1.5, 3.1.10, 3.3. test multiple conditions. Are there
any other tests that could be combined (e.g. the TCP connectivity and EDNS0
tests) without losing fidelity?
(2) Could the retries advised in section 5 be abused to cause a resolver
running roadblock avoidance to send unnecessary test traffic? It seems that
injecting an error, illegal, or bogus response could induce multiple retries,
though it's not clear that the amplification factor makes this worth it.
I think the answer on unnecessary traffic is yes, but the text in the
document suggests retries the Validator MAY run. The text could be
improved to suggest avoid creating amplification issues, however
insignificant.
(2) In section 6, the draft raises the possibility of unstable networking after
connection (e.g. in a captive portal situation); guidance to refrain from flooding the
network with test traffic during this instability might be useful. Perhaps explicitly
link the DNSSEC checks to a "network proves to be usable" signal (either from
the application or the operating system)?
I believe in Section 6 the two options is a trade off between security
(keep testing, and falling test) and usability (waiting for network).
Does;'t the text in 6.1 express this - "the device MAY have a policy of
action, like continue or fail. "
thanks
tim
Thanks, cheers,
Brian (as TSV-ART reviewer)