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

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Hannes Tschofenig writes:
> 
> 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.

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: [phone]                 INTERNET: [e-mail]