On 7-sep-2005, at 1:04, Steven M. Bellovin wrote:
Either the firewall
successfully blocks the protocol and the firewall works and the
protocol doesn't, or the firewall doesn't manage to block the
protocol and the protocol works but the firewall doesn't. So whatever
happens, someone is going to be unhappy.
Not at all. Often, a firewall needs to know a fair amount about the
protocol to do its job. FTP is the simplest case -- it has to look
the PORT (and, in some configuration, the PASV) command. H.323 and
are more complex.
I'm not very comfortable with the notion of having a third party
device deciding what is valid communication between two hosts
connected to the internet. This is just too fragile. For instance, a
popular filter on *BSD (they're all named [i]pf[w] so I can never
remember which is which) is unable to handle RFC 1323 window scaling
properly. PIX firewalls truncate(d) EDNS0 packets. ICMP packet too
bigs are filtered in many places, as is ECN.
I recognize that carrying all existing firewalls to the scrap heop
won't immediately solve our problems, but we do have to realize that
current filter practice do almost as much harm as they do good. We
really need better stuff here.
(It's amusing to see that to some people, security means encrypting
their communication, while to others it means inspecting that same
Ietf mailing list