On Sun, Mar 13, 2011 at 4:51 PM, Justin Pettit <[email protected]> wrote: > 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.
I'm not sure that the other use cases are too interesting (an equivalent script could always be written for other distributions) and it's easy to miss log messages if everything appears to be working so it seems much safer to just not create the tunnel port at all. _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
