Re: A fun smackdown...

["Marcus J. Ranum" <mjr () ranum com>]

Chuck Swiger wrote:
> By definition, the IETF is concerned with systems which interoperate over public networks using network-wide 
> conventions and publicly documented standards.  What people do with private machines or private networks is up to 
> them, at least so long as they *don't* connect those machines to the Internet.

You're completely ignoring the fundamental dilemma that I am trying
to get you to confront. My position in a nutshell:
- "Standards that don't take security into account are not internet-worthy"
and you're asserting
- "If you don't follow standards you break 'legitimate' traffic"

The problem is that, since the standards don't take security into
account, the traffic is not 'legitimate' - it's 'dangerous'   and a
security device can and SHOULD interfere with it.

Maybe the first time someone invents a PMTUD denial of
service attack you'll "get it." 

> A firewall which breaks ESMTP, or HTTP/1.1, or PMTUD to such machines (typically in a DMZ) significantly impacts 
> legitimate access with questionable gains at best for security, and IMHO is a poor tradeoff.  

Well, since it's a matter of opinion, I don't agree with you. :)

Let's look at another example. The RFCs for FTP include
provisions for third party transfer. The PORT command could
be connected to a different host than the client. Historically,
that feature was never used. When I wrote the DEC SEAL
FTP proxy* I realized that this could be used to issue arbitrary
connections. So I deliberately broke from the RFC and put
code in to sever a connection that was attempting this.
So in your terms, since it was in the RFC, it was "legitimate"
but by trashing all over the holy RFC I made networks much
more secure.

So, suppose you're running an older model Gauntlet firewall
or a DEC SEAL. They trash all over the holy RFC by
not even knowing what ESMTP is. Congratulations! If
someone finds a vulnerability that has anything to do
with ESMTP or any option that can be reached via that
code path: you're protected.

> And as for PMTUD, I'd be happy to see a better solution for MTU discovery, short of depending on all intermediate 
> routers to handle IP fragmentation in an efficient and sane fashion.  Do you have something better, Marcus...?

It's kind of you to come to me for all the answers but I'm not a
networking protocol designer - I'm a security system designer.
So don't ask me how to implement something better than the
current PMTUD. On the other hand, I can assert with some
comfort that if I *did* implement some kind of PMTUD it'd be
better than the current approach because it would take
established security techniques and security into account
in its design.

mjr.
(*Yes, hacker kiddies who think you invented FTP bouncing
in 1995 you are completely wrong. Not only was I there
first, I contacted the maintainers of BSD and had a check
added to ruserok() so that the FTP server port was not
treated as privileged...) 

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards