Date: Sun, 08 Apr 2001 05:10:46 +0000 From: Gunther Schadow <gunther@aurora.regenstrief.org> To: snap-users@kame.net Cc: users@ipv6.org, net@freebsd.org, ipfw@freebsd.org Subject: Consolidating KAME SPD rules and IPFW / IPfilter. Message-ID: <3ACFF2D6.13219EAB@aurora.regenstrief.org> References: <3ACD6099.471BE93A@aurora.regenstrief.org> <20010406201920R.sakane@ydc.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, Itojun says this has been discussed before and that the solution is almost ready to go. I can take some time of my dayjob work to help this, which is why I want to know exactly the status and direction. This is my proposal, not knowing what folks at Kame and FreeBSD have been cooking: > [VPN application] In practice I will almost always end up combining > IPFW and IPsec in my security solutions with *BSD/kame. And I find > it kind of odd that IPFW and IPsec shouldn't work together better > than they do now. [...] > > I think that the separate IPsec policy management in setkey is > somewhat superflous. It could all very well be handled by IPFW > rules such as something like this: > > ipfw add 1000 divert ipsecd 1010 all from <here> to <there> out > > ipfw add 1001 divert ipsecd 1020 50 from <there> to <here> in > ipfw add 1001 divert ipsecd 1022 51 from <there> to <here> in > > this means, an IPsec daemon (ipsecd) would listen on a divert > socket (like natd does) and do its thing on the packets. I > understand that the SPD contains more data, and that's what > my numbers 1010, 1020, 1022 would refer to (an SPD identifier). > The SPD would now simply contain the parameters of the IPsec mode > (ESP vs. AH, transport vs. tunnel, tunnel endpoints, etc.) but not > the matching rule stuff. I think that ipfw does a pretty good job > with the matching rules, so why doing the same thing in two places? Itojun wrote in response: > this is the tricky part. IPsec policy and ipfw/ipfilter/divert/ > whatever is doing almost the same thing, and conflict in very difficult > ways. I'm trying to improve NetBSD situation, as shown in > http://www.netbsd.org/Documentation/network/ipsec/#ipf-interaction. > NetBSD 1.5.1/1.6 should be a lot better than before. > > for FreeBSD, there was a discussion on one of FreeBSD mailing lists. > not sure the particular change got committed to the FreeBSD tree or not. > > the ultimate solution would be to integrate packet filter and ipsec > policy engine into one, there's an ongoing effort on that direction. And obviously I fully agree. But the problem for the Kame folks seems to be that the *BSD are disparate and moving targets for consolidating packet filtering and IPsec policy management. Shoichi Sakane wrote: > [...] I am not sure all *bsd have same method to hook a ip packet. > Do all *bsd have ipfw in this case ? I know IPFilter is implemented > to FreeBSD, NetBSD and OpenBSD. But it cannot handle a ipv6 packet > accurately. > > I like to use a general useful pakcet filter function in order to process > IPSec if it is implemented to all *bsd. And he also mentions: > First, KAME IPSec stack is not friendly with NAT. We don't live in NAT > environment, so we haven't ever considered about being with NAT. > If you want to use NAT with IPSec, you have to consider the changing IP > address in IP packet and the processing order. To which I can only say that in IPv4 world and VPN, NAT is almost mandatory. For me, using NAT allows me to set up VPN specific routing for my special project within a corporate network without bothering the network administrator with using FreeBSD instead of their Cisco stuff for routing. FreeBSD/KAME needs NAT for allowing it to being used in production environments today. NAT comes with IPFW, which is where the circle closes. I would prefer combining IPsec policy with IPFW rather than IPfilter. But I may not have the full scoop about IPfilter. What's FreeBSD's direction? I would also rather see one way, IPFW or IPfilter being mainstream on FreeBSD and NetBSD (for very selfish reasons, i.e., once I need to deploy my stuff on a StrongARM board, I must switch to NetBSD.) I like IPFW a lot and my understanding is that it can do more than IPfilter, but I may be wrong? I am tempted to "outsource" the IPsec functionality away from the kernel using a demon on a divert socket, just like NATD. This would be more modular and keeps the kernel from panicing because of bugs in IPsec -- I did have embarrassing kernel crashes, just when I bragged about FreeBSD running rock solid :0(. I have read about pipsecd, but would like to stand by the excellent work of the Kame people. 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-ipfw" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3ACFF2D6.13219EAB>