Since Dave didn't take too kindly to me putting this in the bug
The current IPSec implementation has a distinction in the security
policy between transport and tunnel SAs. I think this is not the best
way to do this. This distinction duplicates work already done by the
ipip driver. We have a tunneling system already, we should use it.
If we mandate the use of the ipip driver instead of doing the tunneling
work, the transport/tunnel distinction can go away, and we can cut out
quite a bit of confusing code.
Also, it is conceivable that an implementation (e.g. AT&T VPN) might use
non-IPIP packets for some kind of out-of-band communication (e.g.
connection keepalive heartbeats). The current system arbitrarily
restricts packets under a tunnel SA to be IPIP only.
It seems to me that we would be better having the AH and ESP drivers
simply do an origin check and unwrap the contents on receive, leaving
the remaining work to other drivers (like ipip.c).
[T]he distinction is necessary to use any pfkey2 based key management
daemons. The distinction is also specified by the IPSEC RFCS. It is
not going away while I'm still alive, therefore.
I'm not sure I understand this. The RFCs specify a difference between
tunnel and transport SAs, yes. That difference is exactly the difference
between directly wrapping packets and passing them through ipip.c before
wrapping them. So why aren't we using ipip.c?
-- Taral <email@example.com> This message is digitally signed. Please PGP encrypt mail to me. "Pretty please with dollars on top?" -- Me
This archive was generated by hypermail 2b29 : Sat Nov 23 2002 - 22:00:00 EST