IPSEC documentation

Brian Candler B.Candler at pobox.com
Wed Dec 28 08:06:47 PST 2005


On Wed, Dec 28, 2005 at 04:04:04PM +0100, Phil Regnauld wrote:
> > This is a really strange approach which is almost guaranteed not to
> > interoperate with other IPSEC gateways.
> 
> 	It's probably for FreeBSD <-> FreeBSD setups, where it might make sense
> 	to have an interface endpoint, rather than the "transparent" IPsec
> 	approach -- otherwise it's not possible to route via the remote
> 	endpoint, or apply filters at interface level before leaving the
> 	gateway.

If it's done that way purely as a workaround for limitations of the FreeBSD
IPSEC architecture then that's OK, but I think it should be explicitly
documented as such. Otherwise the rationale is unclear.

(Presumably by "transparent" IPSEC you mean that the kernel takes care of
IPSEC policy independently of ipfw/pf filtering; you're not talking about a
transparent IPSEC gateway such as
http://www.thought.net/jason/bridgepaper/node12.html )

It's a shame that this workaround means that you actually have to change the
data format on the wire, as this will reduce interoperability. ISTM what you
really want is to be able to have IPSEC tunnels each appear as separate
interfaces, e.g. ipsec0 or tun0, so that firewall policy can be associated
with each one. The old userland IPSEC implementations had this benefit, of
course. Are any of these still maintained and usable? If so then perhaps
they should also be documented as an alternative.

Actually, I did come across a paper which discussed extending the socket API
so that application decisions could be made on the basis of the IPSEC
attributes by which the data was delivered; ah yes, here it is.
http://seclab.cs.ucdavis.edu/papers/314-PHIL.pdf

Integrating something like that with ipfw/pf would also give the flexibility
to associate packets with their IPSEC flows. But I digress.

Regards,

Brian.


More information about the freebsd-net mailing list