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

From: Brian E Carpenter <[email-masked]>
Date: Mon, 19 Oct 2015 15:52:17 +1300

Hmm. I've finally made time to read this draft, to find out what the
fuss is about...

Firstly, I have to find a polite way of saying... well, I can't, so
here it is: delete the Introduction and try again. I think the present
text is guaranteed to annoy just about everybody, and evidently it will
not "end the bickering."

(I gave my own potted history of security in the IETF in the plenary
at IETF 88, slides 2-4.)

Then, I can see 12 RFCs in the index whose titles include the word 'firewall'
and that only scratches the surface; there are literally hundreds of references
to firewalls in existing RFCs. IMHO, if this draft aims to survey the field,
it needs to survey the IETF and non-IETF literature much better (perhaps as
an appendix).

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.

To some more specific comments:

Section 4.1 seems to increase rather than decrease the popular confusion
between firewall functions and NAT functions. I would prefer to see
NAT described in a separate section *as a side issue*. NAT failure modes
are not the same as firewall failure modes.

Section 4.3 cites draft-vyncke-advanced-ipv6-security, which is very dead
as far as I can tell. I don't think we should be citing dead work
in a current IETF draft.

Regards
   Brian Carpenter

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 19 Oct 2015 16:44:37 +0000

>Hmm. I've finally made time to read this draft, to find out what the

:-)

>or an Independent Submission RFC.

+1

---

From: Mark Andrews <[email-masked]>
Date: Tue, 20 Oct 2015 10:16:28 +1100

In message <[email-masked]>, "Blumenthal, Uri - 0553 - MITLL" wr
> >or an Independent Submission RFC.

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: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Melinda Shore <[email-masked]>
Date: Mon, 19 Oct 2015 15:55:22 -0800

> delivered.  Cleaning out old/broken firewalls takes decades.

Right, but vendors do love their firewalls.  It can take an
inordinately long time to get IETF documents out (longer than
it takes to design and implement a product feature) and vendors
are likely to release products that break DNS before a firewalls
draft is done.

I've been watching this discussion and getting a strong sense
of déjà vu, and I think this is going to be a difficult document
to get through the IETF process.  It may be preferable, anyway,
to focus on a series of protocol- or application-specific
firewall problems documents - for example, to move a firewall
considerations for DNS document to dnsop.  It may be the only
way to get consensus about content.

Melinda

---

From: Mark Andrews <[email-masked]>
Date: Tue, 20 Oct 2015 11:38:24 +1100

In message <[email-masked]>, Melinda Shore writes:
Input error
> are likely to release products that break DNS before a firewalls

We will be, DNS COOKIES support will be released early next year
and yes we will hit firewalls that block EDNS queries with unknown
options along with all the other breakage out there.  Somewhere
around 90% of servers will return good answers to those queries.
A couple of percent will be blocked by firewalls.  If the servers
behind those firewalls are serving signed zones then DNS lookups
for those zones *will* fail if the recursive server is validating.
Similarly if they return FORMERR.  Some of the errors are benign
to DNS COOKIES.

Despite the fact that we will be doing this I still think that a
document on firewalls should go ahead.

I also have draft-andrews-dns-no-response-issue which looks at DNS
server misbehaviour and it covers all of these areas.  I've had
feedback that the IETF shouldn't be asking TLD operators to be good
network citizens by running checks on the delegated servers and
informing their operators that they are broken.  I've also had
feedback saying "when are you publishing, this is good stuff".

Mark

---

From: Fernando Gont <[email-masked]>
Date: Mon, 19 Oct 2015 22:05:15 -0300

Hi, Brian,

Thanks so much for your feedback! Please find my comments in-line...

> text is guaranteed to annoy just about everybody, and evidently it will

Point taken. The intro will be replaced. While we're past the I-D
submission cutoff, I'll craft replacing text and post it here for review.

> (I gave my own potted history of security in the IETF in the plenary

Thanks for the pointer. I will go through it.

> it needs to survey the IETF and non-IETF literature much better (perhaps as

Will do.

> or an Independent Submission RFC.

Among other things, I think it is useful in implicitly noting areas
where further work is needed.

> are not the same as firewall failure modes.

I think that people confuse NAT device vs. NAT functionality.

A NAT device enforces, as a side effect, a diode-firewall (only allow
return traffic) functionality. Address Translation itself has nothing to
do with firewalling, but the side a effect does.

That said, we'll move the NAT stuff to a separate section. Other folks
seem to share your opinion, too.

> as far as I can tell. I don't think we should be citing dead work

Point taken. Although they might revise soon -- we'll remove or keep it
based on what they do about it.

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Mon, 19 Oct 2015 22:18:10 -0300

Hi, Melinda,

Thanks so much for your feedback! Please find my comments in-line....

> are likely to release products that break DNS before a firewalls

I think that even with some of the content that we have, plus more
specific stuff (possibly in separate document(s)), at least we have
something to point vendors at.

> way to get consensus about content.

The goal of this document is, to some extent, mostly a high-level
discussion. More detailed stuff should probably be done in separate
documents, and just referenced from this one to keep the problem
"tractable".

Thanks!

Best regards,