On Fri, 12 Jun 2009, David Young wrote:
> <soapbox>
> These difficulties sound like a symptom of the design flaw in NetBSD's
> IPsec that we should not repeat: hard-coding hooks in the IP input
> and output routines. A design that re-used existing abstractions
> to provide building blocks to the operator---for example, an IPsec
> pseudo-interface where the IPsec processing occurs---would be more
> versatile and transparent, and it would spare us some complexity in the
> IP code.
>
> You could attach to an IPsec pseudo-interface both a BPF tap, packet
> filters and translators. It seems that a second attachment point for
> packet filters is what you need here.
> </soapbox>
I have to agree, though I'm not sure it's a flaw with NetBSD per se, but
rather a common thought process "flaw" in the IPsec community right from
the beginning or at least in my initial attempt to understand IPsec.
Many other IPsec implementations I've seen, going right back to long
before any open-source platform supported IPsec, totally avoided having
IPsec appear as a real construct in any of the regular networking stack
-- it was more often just a fictional overlay controlled entirely
separately from the normal TCP/IP stack. If you didn't know the host or
router had IPsec capabilities and that they were configured and working
then you'd never know there was anything different about it until you
put a tap on the network and discovered some or all of the traffic to
and from that host/router was encrypted.
For me this made the whole concept of IPsec, and especially the
practicalities of how to configure it usefully, almost infinitely more
difficult to understand than it should have been. Once I finally
learned about using tunnels with IPsec and such then I could finally
grasp how IPsec was supposed to work and when I looked back at the
original non-tunnelled variant I could finally see what they were
talking about but I still thought it was (and is) a completely warped
concept. To me tunnel mode IPsec should be the only way. I can however
see how non-tunnelled IPsec might be easier to drop down on existing
hosts such that suddenly the network would (hopefully) be more secure
without the hosts having to do anything whatsoever. It's more a
marketing and sales engineering feature than a real technical benefit
though.
After seeing the ultimately simple fix Hubert posted to re-enable PFIL
hooks for IPsec de-encapsulated packets I had a deja vu moment and I
think I can say this silliness has caused problems in other contexts as
well.
I guess the question would be if you're using non-tunnel-mode IPsec then
does passing the de-encapsulated packet through the PFIL hooks again
actually cause any other problems or confusions? I suspect it would.
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 416 218-0099 http://www.planix.com/
Attachment:
pgpMmj829pYHC.pgp
Description: PGP signature