Since Dave didn't take too kindly to me putting this in the bug database: ----- 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). Dave's response: [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 <taral@taral.net> This message is digitally signed. Please PGP encrypt mail to me. "Pretty please with dollars on top?" -- Me
Attachment:
pgp00045.pgp
Description: PGP signature
