Re: [OPSAWG] I-D Action: draft-gont-opsawg-firewalls-analysis-01.txt

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, "Blumenthal, Uri - 0553 - MITLL" wr
ites:
> 
> On 10/18/15, 22:52 , "OPSAWG on behalf of Brian E Carpenter"
> <[e-mail] on behalf of [e-mail]> wrote:
> 
> >Hmm. I've finally made time to read this draft, to find out what the
> >fuss is about...
> 
> :-)
> 
> >Overall, this draft seems to me to be an opinion piece. That's fine of
> >course,
> >everyone is entitled to state their opinion, but I'm not sure that it
> >helps
> >the IETF to know what to do next. It reads more like a CCR editorial
> >article
> >or an Independent Submission RFC.
> 
> +1
> 

Actually it gives good advice to firewall vendors.  In many cases
they do more harm than good by not actually understanding the
protocols that they inspect.  They block extension unnecessarially.

We design a protocol to be future proof and the firewall vendors
stuff up that design for no reason beyond paranoia.

Take the DNS and the handling of EDNS versions > 0.  These were
thought about when EDNS was designed.  There is a specific error
code to be returned BADVERS along with the highest version if EDNS
the server supports.  The client then retries using a common version
of EDNS.  There is NOTHING here that should concern a firewall
vendor.

What do firewall vendors do?  They code the firewall to drop packets
with EDNS version > 0.  This is despite EDNS aware servers having
explict instructions on how to handle these packets.  If the server
doesn't understand EDNS it doesn't matter if the version is 0 or > 0
as it still noise to the nameserver that doesn't understand EDNS.  It
will either ignore the OPT record completely or return FORMERR.

There is no case to be made for dropping these packets.

When one actually wants to use the capabilities we built into the
protocol one then has to fight the firewalls even to get the packet
delivered.  Cleaning out old/broken firewalls takes decades.

Got to https://ednscomp.isc.org/compliance/summary.html and look
at the firewall graphs to see how much damage firewalls are doing
to the DNS for no good reason.  We have mostly removed the broken
firewalls from in front of the TLD servers.

I have no problem with a firewall block a extension temporarially
if it protecting from a known defect in a product while that product
is getting fixed.  They just shouldn't be blocked by default.

One can test products to ensure that they handle packets with
extensions and get the defects fixed.  Most defects are benign and
you will see a lot of them if you look at
https://ednscomp.isc.org/compliance/summary.html but again they can
be fixed.  We have got most of those in the servers the TLD operators
are running fixed.  In doing this testing I've not seen a single
case of a server being knocked over.

Defects like ignoring the EDNS version.  Returning FORMERR to well
formed packets.  Incorrectly copying fields from the request to the
response or I suspect not clearing a fields when turning the request
packet into a response packet.  But you can't get these defects
fixed unless you can see them.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]