Re: [DNSOP] Benoit Claise's No Objection on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with COMMENT)

[Wes Hardaker <[e-mail]>]

"Benoit Claise" <[e-mail]> writes:

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

Section 3.1.3 defines a test to determine if EDNS0 is an issue and
whether a resolver can make of it within the network its deployed in.
So, yes, the draft talks about it.  I don't believe from the above
comment we're missing anything unless you think I've missed your point. 

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

I think this new paragraph should fix these problems (along with the
usage of the words that shouldn't belong in an IETF document).

      NOTE: when performing these tests we also assume that the
      path is clear of "DNS interfering" middle-boxes, like firewalls,
      proxies, forwarders. Presence of such infrastructure can easily
      make a recursive resolver appear to be improperly performing. It
      is beyond the scope of the document as how to work around such
      interference, although the tests defined in this document may
      indicate which such misbehaving middle-ware is causing interference.

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

I see your point, but at the same time we're not trying to test for
compliance of IPv6, and thus we are using A to avoid any other test
failure that may have been as a result of an IPv6 record being fetched.
Though, I admit, that if I resolver can't handle AAAA records there is
pretty much zero chance it can handle DNSSEC.  However, I'd rather tests
be super-narrow in what may break when they issue queries.

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

How does this paragraph sound to address this:

      These tests should be performed when a resolver determines its
      network infrastructure has changed.  Certainly a resolver should
      perform these tests when first starting, but MAY also perform
      these tests when they've detected network changes (e.g. address
      changes, or network reattachment, etc).

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

I need to speak to the author of that sentence to determine his
attention and will get back to it.

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

Thanks so much for your comments!
-- 
Wes Hardaker
Parsons