On Mar 13, 2011, at 11:13 AM, Jesse Gross wrote: > On Fri, Mar 11, 2011 at 10:13 PM, Justin Pettit <[email protected]> wrote: >> IPsec tunnels are only supported on Debian systems running >> ovs-monitor-ipsec. Since that daemon configures IPsec, ovs-vswitchd >> doesn't actually know whether IPsec will actually work. With this >> commit, a warning is printed that it is unlikely to work unless that >> daemon is started. >> >> There is a more serious issue that IPsec traffic can pass unencrypted if >> that daemon is not running. To fix that problem, changes to the kernel >> module will need to occur. A future commit will address that issue, but >> this earlier warning will be useful regardless. > > Why don't we just block the creation of the tunnel? What kernel > changes are you envisioning?
Ben had offhandedly suggested (in face-to-face discussions) that users could have configured IPsec without using our daemon (either because it's not Debian or even not Linux). Clearly, for GRE this doesn't matter, because we don't behave differently depending on whether the traffic is encrypted or not. However, one could imagine a tunnel that behaves differently based on whether or not encryption is handled (e.g., a capwap tunnel could be configured to use a different source port for security policy matching purposes). It's trivial to block the creation, so if you'd prefer that we do it that way (and a strong case can be made for that on security grounds), I'd be happy to make the change. The kernel change I envisioned was at a minimum checking for the SPI on receive. On transmit, I'd imagine there's probably a way to check the XFRM states to ensure that it would be encrypted, but I obviously haven't given it a lot of thought. --Justin _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
