Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 01 May 2001 18:45:38 +0000
From:      Gunther Schadow <gunther@aurora.regenstrief.org>
To:        Lars Eggert <larse@ISI.EDU>
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 ...
Message-ID:  <3AEF0452.C2FD2651@aurora.regenstrief.org>
References:  <3AEEEE79.8F7CC7B0@aurora.regenstrief.org> <3AEEF26B.C6850070@isi.edu> <3AEEF59D.3D5622DE@aurora.regenstrief.org> <3AEEFA06.BA0EB9FD@isi.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3AEF0452.C2FD2651>