In message <5617b205.5030...@gmx.net>, 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: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area