From owner-freebsd-net Tue May 1 11:45:58 2001 Delivered-To: freebsd-net@freebsd.org Received: from rgmail.regenstrief.org (rgmail.regenstrief.org [134.68.31.197]) by hub.freebsd.org (Postfix) with ESMTP id 722CC37B422 for ; Tue, 1 May 2001 11:45:54 -0700 (PDT) (envelope-from gunther@aurora.regenstrief.org) Received: from aurora.regenstrief.org (rgnout.regenstrief.org [134.68.31.38]) by rgmail.regenstrief.org (8.11.0/8.8.7) with ESMTP id f41IojX26841; Tue, 1 May 2001 13:50:45 -0500 Message-ID: <3AEF0452.C2FD2651@aurora.regenstrief.org> Date: Tue, 01 May 2001 18:45:38 +0000 From: Gunther Schadow Organization: Regenstrief Institute for Health Care X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Lars Eggert Cc: snap-users@kame.net, freebsd-net@freebsd.org, ipfilter@coombs.anu.edu.au, altq@csl.sony.co.jp Subject: Re: The future of ALTQ, IPsec & IPFILTER playing together ... References: <3AEEEE79.8F7CC7B0@aurora.regenstrief.org> <3AEEF26B.C6850070@isi.edu> <3AEEF59D.3D5622DE@aurora.regenstrief.org> <3AEEFA06.BA0EB9FD@isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Lars Eggert wrote: > The bad news is that all the gif device does is prepend another IP > header, and call ip_output(). Which means that it has no outgoing queue > to which you could apply ALTQ to. ugh, so that means ALTQ can't be used on the GIF tunnel. The only way to still use ALTQ is if the IPsec ESP still copies the TOS bits from the payload to the encapsulating header. I gather that at least IPsec ESP in tunnel mode would copy TOS up. But I can't use IPsec in tunnel mode right now and you suggested to use the gif tunnel approach. Another unknown to me is whether the GIF tunnel will copy the TOS bits into the wrapper, and so, I can't use ALTQ at all. So, back to square one! :-( > I have used Dummynet on tunnels before and know it works. I assumed ALTQ > would, too - but now that I thought more about it, there are issues. If I don't hear latebreaking news today, I will have to roll everything back to - IPFW + DUMMYNET instead of IPFILTER - GIF tunnels + ESP/transport instead of ESP/tunnel I will first put my configuration under revision control -- forgot to do this in the first place. Once this is done I will revert. This leaves a window of time in which I can still make up my mind based on the latest news. I just hope that in the future we will end up with a *consistent* set of firewall, IPsec, and QoS networking facilities that can all play together happyly and that can be managed at one point. I can see how this could be done in two ways: WAY A: CONTINUE TIGHT KERNEL-COUPLING - KAME to adopt IPFILTER as the one and only KAME-supported wirewall. - 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. WAY B: USE MORE EXTRA-KERNEL PROCESSES - KAME and ALTQ classifier to be combined with IPFW (or an IPFILTER that supports the DIVERT mechanism.) - KAME security ESP, AH, and IPCOMP transforms to be implemented as daemons on the DIVERT socket - IPFW rules then control the IPSEC and DUMMYNET functions and ALTQ remains at the interface between link layer and physical layer, but using the classifier on the upper layer. > Maybe Kenjiro and Itojun (who have a much better understanding of the > details of the networking stack than me) have some ideas how to make > this work? I'll stay tuned and flexible. My goal is to do it the right way, the standard way, but right now it looks like the standards or their implementations are not really designed to work together, not just yet. regards, -Gunther -- Gunther Schadow, M.D., Ph.D. gschadow@regenstrief.org Medical Information Scientist Regenstrief Institute for Health Care Adjunct Assistent Professor Indiana University School of Medicine tel:1(317)630-7960 http://aurora.regenstrief.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message