Skip site navigation (1)Skip section navigation (2)
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-net" in the body of the message




Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?3ACFF2D6.13219EAB>