TSV-ART review of draft-ietf-dnsop-dnssec-roadblock-avoidance

[Brian Trammell <[e-mail]>]

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.

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.

(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)?

Thanks, cheers,

Brian (as TSV-ART reviewer)