Date: Thu, 15 Aug 2002 10:15:05 -0400 From: Bosko Milekic <bmilekic@unixdaemons.com> To: Luigi Rizzo <rizzo@icir.org> Cc: ipfw@FreeBSD.ORG Subject: Re: RFC: new mbuf flag bit needed Message-ID: <20020815101505.A8332@unixdaemons.com> In-Reply-To: <20020815000720.B24495@iguana.icir.org>; from rizzo@icir.org on Thu, Aug 15, 2002 at 12:07:21AM -0700 References: <20020815000720.B24495@iguana.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Aug 15, 2002 at 12:07:21AM -0700, Luigi Rizzo wrote: > [Bcc to -arch in case they have some comments] > > Hi, > we have the following problem: both ipfw and ipfw2 can sometimes > generate new packets (e.g. in response to an "unreach" or "reset" > action, or simply keepalives) which in turn get reinjected in the > stack and the firewall itself, starting from the beginning. This > has the potential of causing loops, unless we break them in some > way. > > ipfw does this using two specific hacks: > + ICMP packets will not generate a response even on "unreach" rules; > + TCP packets with the RST bit set will not generate a response > on "unreach" rules) > > ipfw2 has a harder time because keepalives have nothing very > distinguishable in them (except sequence numbers which refer to old > data; but to detect them requests a lookup of the stateful entry). > > So my proposal is to use a different method, and use one of the > m_pkthdr.flags bits as a marker that the packet should bypass the > firewall. I can restrict the change to just ip_fw2.c so no other > parts of the system will need to be modified, except sys/mbuf.h for > the definition of the new bit if we want to give it a meaningful name. This sounds like it could warrant its own flag in sys/mbuf.h, say M_BYPASS_IPFW, instead of using one of the M_PROTO flags. I just made m_flags an int instead of a short so you should have plenty of available bits now. You can do the same in RELENG_4. > sys/mbuf.h contains definitions for M_PROTO1..M_PROTO5; the first > one is used to mark that rcvif is valid on vlan packets (btw should > we rename it to indicate its real use ?). It's safe to use one of the M_PROTO flags only if you know that the other layers the mbuf chain will pass through will not use it. What I mean is that it's only ok if you know that, say, "there is no way that the packet I am looking at can be vlan, I am using M_PROTO1 just for internal things." In general, I think that for your case, where the packet is re-inserted into the stack, you have a good enough reason to define your own flag in sys/mbuf.h > The others are used in the KAME code in netinet6/ -- i guess that > leaves me with using one of the two unused bits, 0x4000 and 0x8000 ? > > cheers > luigi Cheers, -- Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020815101505.A8332>