In some mail from YAMAMOTO Takashi, sie said:
> 
> > It is not just for ipf, but that is one of the two beneficaries.
> > The other is BPF (tcpdump.)
> 
> tcpdump can decode ESP by itsself and i think it should if needed.
> it already has -E option.  it's a bit limited currently, though.

Uh, how does it do that ?

Oh, I see:

                case 'E':
#ifndef HAVE_LIBCRYPTO
                        warning("crypto code not compiled in");
#endif
                        espsecret = optarg;
                        break;

And it only fixes the problem for tcpdump and not all
applications that want to use BPF to look at unecrypted
traffic - which I think is an unnecessary burden.

Not to mention that it won't work if you have multiple
tunnels or transports using different encryption keys.

If, for example, I was using NetBSD as a VPN server, I
might want to examine all of the traffic going to the
clients, unencrypted and it would be cumbersome to
have to keep track of all the individual keys.  As a
debugging tool, using tcpdump with -E is good for
tracking down and diagnosing individual problems.

You couldn't, for example, use this mechanism with snort
to run an IDS against the traffic that otherwise gets
encrypted.

> > but so far, after much frustration to many people, there would appear to
> > have been no better idea ?  Consider that there are two targets here that
> > we want to fix the problem for - tcpdump et al & ipfilter.  Solving the
> > problem for ipfilter with fancy pfil stuff is not going to work for
> > tcpdump.
> 
> i don't think that ipfilter and tcpdump should use the same mechanism
> to solve this "problem".
> 
> i think that additional pfil filtering points, e.g. inet_decoded_pfil_hook,
> is enough for ipfilter.  am i missing something?

Yes, you need to be able to distinguish how the rules are applied.

e.g. with this method, rules would be similar to:

block in on ipsec_pcn0 all
pass in on ipsec_pcn0 proto tcp from any to any port = 25
pass out on ipsec_pcn0 proto tcp from any port = 25 to any

Furthermore, displaying those loaded into the kernel produces
similar output and they make (to me :) perfect sense.

However, some sort of solution needs to be determined so that
hosts running as bridges can use IPFilter on the bridged traffic
in an independant fashion to that for normal IP in the case of
a mixed role "router/bridge".

Darren