[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[altq 812] Re: The future of ALTQ, IPsec & IPFILTER playing together ...
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
- 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.
Gunther Schadow, M.D., Ph.D. email@example.com
Medical Information Scientist Regenstrief Institute for Health Care
Adjunct Assistent Professor Indiana University School of Medicine