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

From: "Benoit Claise" <[email-masked]>
Date: Thu, 07 Jul 2016 02:31:30 -0700

Benoit Claise has entered the following ballot position for
draft-ietf-dnsop-dnssec-roadblock-avoidance-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-roadblock-avoidance/

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

---

From: Ray Bellis <[email-masked]>
Date: Thu, 7 Jul 2016 10:35:56 +0100

On 07/07/2016 10:31, Benoit Claise wrote:

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

This is the wrong way around - EDNS *relies upon* fragmentation working.

Absent EDNS, the response would be constrained to the original RFC 1035
limit of 512 octets.

Ray

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 7 Jul 2016 13:06:12 +0000

Badly worded of mine... Firewalls drop/dropped EDNS0 packets which was the
core issue

-éric

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 08 Jul 2016 15:21:30 -0700

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

> restriction does not appear as realistic to me in the current

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.

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

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

> 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

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 18 Jul 2016 11:44:22 +0000

Wes,

Sorry for late reply, I was part-time on vacations and part-time too busy.

Regarding the EDNS0, it was more related to flow of the I-D where EDNS0 is
introduced rather late in the document. But, I am fine with leaving the
document as it is.

Thanks for the modified pieces of text: they are good for me

-éric