Subject: Re: [Int-area] [OPSEC] "On Firewalls in Internet Security" (Fwd: New Version Notification for draft-gont-opsawg-firewalls-analysis-00.txt)

From: Fernando Gont <[email-masked]>
Date: Fri, 9 Oct 2015 07:25:53 -0300

Hi, Eric,

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

On 10/05/2015 12:57 PM, Eric Vyncke (evyncke) wrote:
> Fernando, Fred and Paul,
> 
> Sorry for belated reply, here are a couple of comments:
> 
> The title is a little ambiguous IMHO it is "On Firewalls in Security"
> (because they also apply inside an 'intranet') or "On Firewalls in
> Internet Protocol (IP) Security" or "On firewalls and Security of the
> Internet" ?

How about "On Firewalls in Network Security"?

> The introduction looks more like an history, so should perhaps be renamed?

How about splitting the historical part into a stand-alone section
renamed as "Firewalls in the IETF" or the like?

> Terminology section should perhaps appear more like an usual terminology
> section and not as a free-form text?

mm.. I guess that from the current contents we can define "firewall" and
"perimeter"?

> Section 3.2 (end to end principle) is interesting but is a little complex
> to read.

Any suggestions on how to improve the text?

> Section 3.3, unsure whether I am reading it correctly but I don't agree
> with the statement that firewall can protect the (network) infrastructure
> against DoS attack (as hinted by "message volume overwhelms"). Rate
> limiters or DoS scrubbing devices do not qualify as 'firewall' IMHO.

Could you elaborate a bit?  e.g., why wouldn't a rate-limited qualify as
a firewall?

> I think section 3.4 (a good one) rather belongs to section 4 and should
> align the taxonomy.

Yep. Looks like we could move this into the base Section 4. (Or were you
meaning something else?)

> Section 4.1, split the first paragraph in two parts. The second one being
> the example given => to make it clear that the "sessions may never be
> initiated from the outside" belongs to the example only

OK, will do.

> Section 4.1, 2nd paragraph, the word 'testing' has an active tone in my
> (non native) English, why not using a more passive verb such as "inspect"
> or "check" ?

Agreed. Will do.

> Section 4.1, at the risk of appearing as 'purist', I would move the NAT
> section from this section and create one on this topic.

Please let me think about this one. f you have any suggestions regarding
whre in the I-D you'd put such a section, please let me know.

> Section 4.2, or rather the perimeter exists but it very very small : one
> physical link :-) or wider: one logical perimeter without any strict
> geographical boundaries.

Yes. :-)

> Section 4.2, should make it clear that the 'tagging' is required (being
> IEEE 802.1Q VLAN tag or ...),

OK.

> and, the end of the section is rather
> negative on this specific FW.

I see... any hints for improvement?

> Section 4.3, I like it of course :-), and I agree there are now scalable
> algorithm to detect anomalies even with a single node (thanks to
> self-learning :-))

Could you elaborate a bit? :-)

> Section 4.3, "Reputation databases have a bad reputation" is a fun
> sentence :-)

Indeed! :-)

> Section 5, I would also use the words of white and black lists as they are
> well-known. I wonder also why there is a specific section 5.1 without a
> section 5.2? 

Section 5.2 was forthcomming... (will hopefuly be there in version -01
of the I-D)

> I would remove this heading and keep the text. Don't forget
> to mention HTTP 2.0 & works such as QUIC.

Will do.

> Section 6, should also mention that FTP & SIP can be used for dynamic
> ports.

Will do.

> It should also mention/repeat that port 80 is not only about HTTP
> but for many protocols 'tunneled' over HTTP.

Will do.

> Section 6, temporary addresses are indeed annoying in some cases but IP
> addresses can also be spoofed.

What we meant here is that things like IPv6 temporary addresses change
such assumption.

But yes, we should comment on spoofing.

> Should mention anti-spoofing? And/or IPSEC
> AH?

Anti spoofing in terms of RPF, or something else?

> Section 7 is about layer-3/layer-4 'packet filtering' which is a specific
> kind of firewalls while the I-D title appears to be more generic. I
> suggest to keep the section but make title more specific and add some
> introduction sentences to this section.

Good grief! Will do.

> Section 8, kind of repeats a former point... Useful text but should unify
> and at a single location

You mean with Section 4.1?

> Section 10 is of course looking for heated comments from the community...

[FWIW, Section 10 will be split into a different document... such that
the heat happens elsewhere :-) ]

> Here are a couple:
> - wonder whether the IETF could have recommendations for all cases?

Certainly not for all -- but better to have something covered, than
nothing :-)

> Moreover, situation will probably continue to evolve
> - zone-based should also allow ICMP inbound ;-)

.... if they relate to an ongoing session?

> There are also important (IMHO) topics MISSING:
> - more and more traffic are encrypted, good for privacy, bad for firewalls
> as they are blind now and mostly useless

Yes and no.

If you mean TLS, it prevents DPI, but still allows for filtering based
on port numbers...

> - recommendation for NOT BLOCKING traffic over the Internet (except to
> each ISP own infrastructure)?

not blocking which sort of traffic?

> - logging / auditing function is missing (talking about security here)
> - logging of event is missing (talking about operation here)

Do you mean in the recommendations section, or elsewhere?

Thanks so much!

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 9 Oct 2015 14:24:37 +0200

Dear authors,

Who is the target audience for this document?

Do you think that audience cares about your opinion particularly since
firewalls are around for a little while already? (One might argue that
you are about 20 years late with this document.)

Aren't you worried that readers might think you are a bit biased? I
would be more interested to read a document written by an end-host-based
firewall manufacturer that argues for the deployment of network-based
firewalls.

Ciao
Hannes

PS: The recommendations do not appear to be new and have been mentioned
in other documents already.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 12 Oct 2015 11:25:51 +1100

> in other documents already.

Lots of the content is pertanent today.  Look at the treatement of
DNS packets in todays firewalls.

It took years to get EDNS packets larger then 512 bytes through
most firewalls by default.  Some still block packets bigger than
512 bytes.

There are firewalls that block queries that are not in a small set
to types.

There are firewalls that block fragmented responses leaving the
site.  Who is the firewall protecting in this case and is it really
the firewall's job to do that protection?

There are firewalls that block fragmented responses to outgoing
queries.  How hard is it to add permit <src-addr,dst-addr,proto=udp,
fragoffset!=0> when adding <src-addr,dst-addr,proto=udp,src-port=53,
dst-port=???> to allow reply traffic through?  Open up a slit for
the non initial fragments.

There are still firewalls that block queries with the DO bit.  This
breaks DNSSSEC.

There are firewalls that block queries with the AD bit.  The use
of AD is documented in RFC 6840.

There are firewalls that block queries with the last reserved DNS
header bit set.  The bit should be ignored by the server.

There are firewalls that block requests with a unknown opcode.  This
should elicit a NOTIMP from the server.

Firewalls are blocking EDNS packets with the version != 0 which
breaks EDNS version negotiation and with that the ability to use
the feature reliably in future enhancements.  This is despite the
initial EDNS specification (RFC 2671) saying to return BADVERS to
such packets.

Firewalls are blocking EDNS packets with unknown EDNS flags despite
the initial EDNS specifiction (RFC 2671) saying that servers need
to ignore them.

Firewall that block unknown EDNS options.  This is going to impact
on the deployment of EDNS COOKIES.  Unknown EDNS options are supposed
to be ignored, RFC 6891.  This behaviour was undefined in RFC2671.

The DNS is a query response protocol.  If you don't get response
it is a little hard to tell if the server is down, if a packet just
got lost, if there is a router down or if it is a stupid firewall
vendor that thinks it is useful to drop well defined queries with
well defined response behaviour specified.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Tue, 13 Oct 2015 09:13:00 -0300

Hi, Hannes,

> Who is the target audience for this document?

Everyone that may care about firewalls and/or their implications.

> you are about 20 years late with this document.)

I don't think I could possibly assess what the audience (as a whole)
cares about. Besides, I don't have much of a big ego to expect people to
care what *I* think. What I *can* tell is that a number of people have
already expressed that they found the document to be valuable. And I
would expect people to care about the topic and the content of the
document, regardless of who happens to be the author.

Regarding the timeliness... I guess that, because firewalls *are*
being deployed for v6, we have the "luxury" of doing things right this
time.

> firewall manufacturer that argues for the deployment of network-based

To be honest, what would really worry me would be if, rather than
focusing on the technical content of the I-D, people fall into
"argumentum ad hominem" (https://en.wikipedia.org/wiki/Ad_hominem) --
particularly if they are speculations.

(FWIW, I never bought the argument that "the security paradigm will move
from network centric to host centric" -- both because (for years) it has
not been network centric (but rather mixed host/network-centric) and
because I don't find any concrete and compelling reasons for which that
will change. However, such argument is not the focus of this document
(at least, not yet). I'd say that both kinds of firewalls serve a
different (and rather complimentary) purpose.)

That said, if you find any bias or room for improvement in the document,
please do let us know.

> in other documents already.

FWIW, the recommendations will be moved out into a separate document.

Thanks!

Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 15 Oct 2015 05:23:02 -0300

Hi, Mark,

Thanks so much for your input Comments in-line...

> most firewalls by default.  Some still block packets bigger than
[....]

Question: Has all of this been summarized somewhere?

If not, it would seem that it would be desirable to explicitly include
all this evil behavior in e.g. the forthcoming "advice" document.

Thoughts?

Thanks!

Best regards,

---

From: Mark Andrews <[email-masked]>
Date: Thu, 15 Oct 2015 19:29:54 +1100

> Question: Has all of this been summarized somewhere?

Parts of it show up in EDNS compliance failures graphs at
<https://ednscomp.isc.org/compliance/summary.html>.  There
are server level reports the last compliance run at
<https://ednscomp.isc.org/> as well as a online tester.

draft-andrews-dns-no-response-issue also talks about parts
of it.

> all this evil behavior in e.g. the forthcoming "advice" document.

Perhaps.  Pointing out badness is the first step to getting it
fixed.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 12 Oct 2015 14:01:30 +0000

On 10/11/15, 20:25, "OPSAWG on behalf of Mark Andrews"
<[email-masked] on behalf of [email-masked]> wrote:

>Lots of the content is pertanent today.

That’s not a good reason for writing a new document containing the old
recommendations…?