From owner-freebsd-net  Tue May  1 17:40:39 2001
Delivered-To: freebsd-net@freebsd.org
Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97])
	by hub.freebsd.org (Postfix) with ESMTP id B79B337B424
	for <freebsd-net@freebsd.org>; Tue,  1 May 2001 17:40:36 -0700 (PDT)
	(envelope-from itojun@itojun.org)
Received: from itojun.org (localhost [127.0.0.1])
	by coconut.itojun.org (Postfix) with ESMTP
	id 4F9344B10; Wed,  2 May 2001 09:40:28 +0900 (JST)
To: snap-users@kame.net
Cc: freebsd-net@freebsd.org, ipfilter@coombs.anu.edu.au,
	altq@csl.sony.co.jp
In-reply-to: gunther's message of Tue, 01 May 2001 18:45:38 GMT.
      <3AEF0452.C2FD2651@aurora.regenstrief.org> 
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: (KAME-snap 4593) Re: The future of ALTQ, IPsec & IPFILTER playing together ... 
From: itojun@iijlab.net
Date: Wed, 02 May 2001 09:40:28 +0900
Message-ID: <5342.988764028@itojun.org>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

>WAY A: CONTINUE TIGHT KERNEL-COUPLING
>
>- KAME IPsec, ALTQ and IPfilter's rules engine to be combined
>  into one classifier.
>
>- IPFILTER ---> IPSEC ---> ALTQ to be placed in this order of
>  processing (on outgoing packets)
>
>- IPSEC to make sure the packet labels attached by the classifier
>  are available for ALTQ even after encapsulation.

	the problem is not this simple.  if the problem is this simple, we
	should have solved this already and KAME would have been disbanded :-)

	i guess you are looking at originating case (packets generated by the
	router itself).  however, there are other items you need to look at.
	try to think about outbound path too, and forwarding path.  ipfilter,
	IPsec and ALTQ wants to filter at different point in the code path,
	and they would like to look at different portions.

	for originating case your way (look at packets before encapsulation)
	makes sense for your particular example.  however,
	- when people who use ipfilter/ipsec/ipnat/altq for different purposes,
	  they want a different ordering of events.  for example, there are
	  people who want to filter packets after IPsec encapsulation.
	- another example, i guess the order won't work if you run ipnat
	  (NAT portion of ipfilter).

	this is a hard problem, and I guess I can never solve it perfectly.
	IMHO, all the mess came from the very concept of tunnelling, private
	address reuse (NAT), and other things.  i like diffserv, but i would
	like to see it without NAT nor tunnelling.
	maybe this is one of the reasons I'm more into IPv6, IPsec transport
	mode, and the world without tunnelling... :-)

	if you have various commercial vendor routers, please try to decipher
	what they are doing internally about it, from the manuals.
	maybe it gives you a good hint (or bad hint).

itojun

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