[ovs-dev] [PATCH] netdev-vport: Warn on IPsec tunnels when ovs-monitor-ipsec not running.

Ben Pfaff blp at nicira.com
Mon Mar 14 12:54:51 PDT 2011


On Mon, Mar 14, 2011 at 12:50:59PM -0700, Jesse Gross wrote:
> On Sun, Mar 13, 2011 at 4:51 PM, Justin Pettit <jpettit at nicira.com> wrote:
> > On Mar 13, 2011, at 11:13 AM, Jesse Gross wrote:
> >
> >> On Fri, Mar 11, 2011 at 10:13 PM, Justin Pettit <jpettit at nicira.com> 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.

My example is pretty hypothetical so I'm happy to go with Jesse's
preference too.



More information about the dev mailing list