From owner-freebsd-security  Thu Mar  1  1:49:26 2001
Delivered-To: freebsd-security@freebsd.org
Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97])
	by hub.freebsd.org (Postfix) with ESMTP id 748CB37B718
	for <freebsd-security@freebsd.org>; Thu,  1 Mar 2001 01:49:20 -0800 (PST)
	(envelope-from itojun@itojun.org)
Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1])
	by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id SAA20259;
	Thu, 1 Mar 2001 18:49:13 +0900 (JST)
To: Darren Reed <darrenr@reed.wattle.id.au>
Cc: freebsd-security@freebsd.org
In-reply-to: darrenr's message of Thu, 01 Mar 2001 20:41:38 +1100.
      <200103010941.UAA10618@avalon.reed.wattle.id.au>
X-Template-Reply-To: itojun@itojun.org
X-Template-Return-Receipt-To: itojun@itojun.org
X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD  90 5F B4 60 79 54 16 E2
Subject: Re: IPFILTER IPv6 support non-functional?
From: itojun@iijlab.net
Date: Thu, 01 Mar 2001 18:49:13 +0900
Message-ID: <20257.983440153@coconut.itojun.org>
Sender: owner-freebsd-security@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org


>> 	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.

	i highly recommend you to avoid m_pullup at all, and use m_copydata
	as necessary.  m_pullup works only if the header part is
	smaller than MLEN (there's no upper bound in ip6 header length).
	once m_pullup fails, the packet will go away - this is not desirable.

	also, i remember that there are functions in fil.c that pass around
	memory regions without passing memory region length...
	i'd like to suggest to pass around mbuf *, but i know that the
	portability issue will not permit that to you.  so i'd recommend
	to always pass around <buf + length> pairs

>Anyway, once all that is sorted out, the filtering will be limited to
>what can be done with IPv4 options - is that sufficient ?

	i guess so, but i'm not 100% certain.

itojun

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message