Date: Tue, 01 May 2001 17:12:25 +0000 From: Gunther Schadow <gunther@aurora.regenstrief.org> To: snap-users@kame.net, freebsd-net@freebsd.org, ipfilter@coombs.anu.edu.au, altq@csl.sony.co.jp Subject: The future of ALTQ, IPsec & IPFILTER playing together ... Message-ID: <3AEEEE79.8F7CC7B0@aurora.regenstrief.org>
next in thread | raw e-mail | index | archive | help
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. 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?3AEEEE79.8F7CC7B0>