Eric, If you read what he posted and really believe that is what he is saying, you need to re-think your career decision. It is obvious that he is not saying that.
I hate it when threads breakdown to this type of tripe and ridiculous restatement of untruths. - Brian > -----Original Message----- > From: Eric Wieling [mailto:ewiel...@nyigc.com] > Sent: Tuesday, April 22, 2014 1:16 PM > To: Dobbins, Roland; nanog@nanog.org > Subject: RE: Requirements for IPv6 Firewalls > > It seems to me you are saying we should get rid of firewalls and rely on > applications network security. > > This is so utterly idiotic I must be misunderstanding something. There are > a > few things we can count on in life, death, taxes, and application developers > leaving giant security holes in their applications. > > -----Original Message----- > From: Dobbins, Roland [mailto:rdobb...@arbor.net] > Sent: Saturday, April 19, 2014 12:10 AM > To: nanog@nanog.org > Subject: Re: Requirements for IPv6 Firewalls > > You can 'call' it all you like - but people who actually want to keep their > servers up and running don't put stateful firewalls in front of them, because > it's very easy to knock them over due to state exhaustion. In fact, it's far > easier to knock them over than to knock over properly-tuned naked hosts. > > Also, you might want to search the NANOG email archive on this topic. > There's lots of previous discussion, which boils down to the fact that serious > organizations running serious applications/services don't put stateful > firewalls (or 'IPS', or NATs, et. al.) in front of their servers. > > The only way to secure hosts/applications/service against compromise is via > those hosts/applications/services themselves. Inserting stateful > middleboxes doesn't actually accomplish anything to enhance confidentiality > and integrity, actually increases the attack surface due to middlebox exploits > (read the numerous security notices for various commercial and open-source > stateful firewalls for compromise exploits), and has a negative impact on > availability. > >
