Hi,
at the risk of flooding the net with my thoughtbubbles: I (eventually)
need to use ALTQ, IPsec and IPFILTER alltogether on one FreeBSD set-top
box machine (PicoBSD). And I'm afraid of interactions or mutual
exclusions of these packages. I did make IPsec and IPFILTER work
together (that is, I still haven't quite made IPsec do what I need
to do, but that's another story.) But when ALTQ comes in, what
will happen?
BACKGROUND: I am building a VPN tunnel endpoint, to be deployed in
numbers of 5 now (future: 10, 100, ...). This endpoint is connected
to the Internet through DSL or Cable Modem. Basic requirements are:
- to establish IPsec ESP tunnels from each remote site to a
central site, implementing an IPv4 virtual LAN within one
local address range (i.e., 10.0.0.0/8).
- to protect the network from attacks entering through the remote
sites, i.e., firewall (IPFILTER)
- to manage the low uplink bandwidth from the remote sites.
This bandwidth problem is where ALTQ comes in. Our Cable Internet
provider limits uplink bandwidth to about 100 kbps only while
downlink bandwidth is about 2 Mbps. The application we have is
videoconferencing. We have an asymmetric video requirement,
where we only need video from the central to the remote sites
to be of good quality, we need audio to be good in both directions
and remote camera control to be good from remote to central. While
our video conferencing application cannot be adjusted very well
to those assymetric requirements, it lets me discern the various
data streams using the type of service (TOS) field in the IP header.
So, I was going to use ALTQ at the remote site to give priority to
outgoing camera control, and audio and to downgrade the outgoing
video to the small bandwidth that remains.
However, I understand that ALTQ works in the data link layer at
the interface to the NIC. IPsec, however, works above that layer,
even before the IPFILTER rules (on outgoing packets.) So, we have
the following "pipe"
IPSEC -----> IPFILTER -------> ALTQ
the problem is that ALTQ will only see IPSEC ESP packets. So,
all the properties of the payload packets that allow me to
define the ALTQ classes are now encapsulated in ESP and thus
invisible to the ALTQ classifier.
I believe that this is a major obstacle right now that will
fail my project. Instead I will have to revert back from IPFILTER
to IPFW (FreeBSD) so that I can use DUMMYNET instead of ALTQ.
This leaves me with having to add a TOS-based filtering into
IPFW. Cross my fingers and it will work :-/
The morale of this story should be: It is VERY IMPORTANT that
the packet classifying / filtering rules of IPSEC (SPD),
IPFILTER and ALTQ be consolidated very soon. The way this
should work is:
CLASSIFIER --> IPFILTER -----> IPSEC -----> ALTQ
The common classifier would have all these rules that
match the from and to and port and TOS and other
properties of the packets. The classifier would assign
some (set of) label(s) to each packet. Upon that label
the IPFILTER would drop, (proxy or whatever), the IPsec
would enforce security policies like ESP, AH, and IPCOMP
transforms. It is important that the CLASSIFIER's label
would stick to the packet even after it's been ESPed by
IPSEC, so, finally the ALTQ can do its flow control
work based on the label.
If we keep the filter matching rules separate in IPFILTER,
IPSEC and ALTQ for much longer, this is only duplicating
the maintenance work and will prevent these three great
packages to work together happily.
regards,
-Gunther
--
Gunther Schadow, M.D., Ph.D. [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
