Date: Thu, 1 Mar 2001 20:41:38 +1100 From: Darren Reed <darrenr@reed.wattle.id.au> To: itojun@iijlab.net Cc: freebsd-security@freebsd.org Subject: Re: IPFILTER IPv6 support non-functional? Message-ID: <200103010941.UAA10618@avalon.reed.wattle.id.au> In-Reply-To: <19523.983437566@coconut.itojun.org> from "itojun@iijlab.net" at "Mar 1, 1 06:06:06 pm"
index | next in thread | previous in thread | raw e-mail
In some email I received from itojun@iijlab.net, sie wrote:
> >But at the same time they WILL NOT MATCH "pass tcp packets" either.
> >
> >Generally, the policy should be "block everything, permit what you want"
> >and in that case you would end up dropping things with IPPROTO_ROUTING,
> >etc. Even a basic ruleset like:
> >
> >block in all
> >block out all
> >pass out proto tcp/udp all
> >pass in proto tcp/udp all
> >
> >will block all the IPv6 packets with routing headers, etc.
>
> but then what if you would like to permit packets with extension
> headers? or like only certain combinations?
> most of the existing packet filter languages have the same issue, btw.
Or even, what if you want allow particular combinations or sequences or
maybe chains of a particular length ?
As it is, IP Filter can easily filter on whether a particular extension
header is there or not once I make it recognise them using a procedure
similar to looking for IP options in fr_makefrip(). What'll actually be
harder is looking for all the assumptions about the "final protocol
header" being the "next header" after the IPv{4,6} header and making
sure as much as possible goes into the *same* mbuf. Ugh.
Anyway, once all that is sorted out, the filtering will be limited to
what can be done with IPv4 options - is that sufficient ?
Darren
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103010941.UAA10618>