This is the nature of stateless firewall-filters guys... It has been this way since the beginning and everybody else seems to understand this behavior. I don't see anybody else screaming that this is a gaping security hole. You do realize that this is no different than ACLs on Cisco right? If you need something that will handle traffic statefully, use a firewall instead.
Stefan Fouant JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant Sent from my iPad On Aug 19, 2011, at 6:33 PM, Nick Kritsky <nick.krit...@gmail.com> wrote: > "inconsistency"? > I would say "gaping security hole". I wonder how many routers out there are > setup to pass any IP packet with ACK bit turned on. > > Nick > > On Fri, Aug 19, 2011 at 5:50 PM, Stefan Fouant > <sfou...@shortestpathfirst.net> wrote: > Hi Saku, > > 'tcp-established' or any of the other TCP bit-field match conditions do > assume an implied TCP, but they aren't actually checking to see if the > protocol is actually TCP. Therefore, they are simply looking for a bit to be > on or off at a specific offset where those fields would be if the packet was > actually TCP. > > What this means is that if the packet is anything other than TCP, and a > protocol match type of TCP is not specified, other packets may match if the > bit is set at that particular offset. > > This isn't really an "inconsistency" as you say and there are no real useful > applications here... This is why the Juniper documentation and other > literature is explicit to point out that you should always use a 'protocol > tcp' match when using these bit-field conditions... > > HTHs. > > Stefan Fouant > JNCIE-M, JNCIE-ER, JNCIE-SEC, JNCI > Technical Trainer, Juniper Networks > http://www.shortestpathfirst.net > http://www.twitter.com/sfouant > > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
