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

[Wes Hardaker <[e-mail]>]

Brian Trammell <[e-mail]> writes:

> 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.

Thanks for the review and the concentration the transport side of
things.  Sorry for the delay in this response (it was a busy month).

> (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.

Most of the tests are to local recursive resolvers, so I don't think
there will be a traffic issue.  Even then, the number of packets sent
from all the test is massively dwarfed by most devices HTTP packets, eg.
We're very much in the weeds with respect to the average use by
everything else the device is spinning up for in the first place.

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

DNS doesn't allow for the combining of questions into a single packet,
but we do note where some "quick tests" may be able to trump other
tests.  It's also, as we note, possible to do many tests in parallel as
well.  I do think we've done the best we can there.

> (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.

Well, an attacker could do that with any other DNS traffic too.  So I
don't think we're adding to the problem.  If anything, we're taking away
from it because we're preventing clients from believing untrustable data
when it should be dnssec signed.  Without our detection mechanisms,
clients that assume they have no ability to do DNSSEC are much much
worse off and subject to many more problems.

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

Well, the trick is how to discover that?  If you follow our checks in
serial, then you'll already stop.  But it's very hard to prove that a
network is unstable.  Again, each test is functionally a packet or two
so the general tests will take up 15*2 packets on average, say, and I'll
double it again just to be safe and say 60 total (including both
directions).  Compare that with the DNS lookups done just to look up the
average web page with all it's sub-domains and social buttons inside
(hint > 100 for most news sites, for example.  Much more than 100 in
fact) and we're very much in the weeds with traffic.

-- 
Wes Hardaker
Parsons