Re: [GIT PULL v2] Open vSwitch

[Ben Pfaff <blp-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>]

On Mon, Nov 28, 2011 at 09:02:34AM -0500, Jamal Hadi Salim wrote:
> On Mon, 2011-11-28 at 21:04 +0800, Herbert Xu wrote:
> > However, what's more worrying for me right now is the gaping
> > DoS opportunities that exist in the patch as is.
> > 
> > In particular, the whole design principle of punting all new
> > flows to user-space is an excellent way of attacking the system.
> 
> Indeed this is an issue with openflow in general.
> The general solution is to rate limit how much goes to the controller
> but even that is insufficient.

Regarding OpenFlow rate limiting, in addition to Martin's response, Open
vSwitch has implemented controller rate limiting since day one.  It is
documented in ovs-vswitchd.conf.db(5):

     OpenFlow Rate Limiting:

       controller_rate_limit: optional integer, at least 100
              The maximum rate at which packets in unknown flows will be  for-
              warded  to the OpenFlow controller, in packets per second.  This
              feature prevents a single  bridge  from  overwhelming  the  con-
              troller.   If  not specified, the default is implementation-spe-
              cific.

              In addition, when  a  high  rate  triggers  rate-limiting,  Open
              vSwitch  queues  controller  packets for each port and transmits
              them to the controller at the configured rate.   The  number  of
              queued  packets  is limited by the controller_burst_limit value.
              The packet queue is shared fairly among the ports on a bridge.

              Open vSwitch maintains two such packet rate-limiters per bridge.
              One  of  these  applies  to  packets  sent  up to the controller
              because they do not correspond to any flow.  The  other  applies
              to  packets  sent  up  to the controller by request through flow
              actions. When both rate-limiters are filled  with  packets,  the
              actual  rate  that  packets  are sent to the controller is up to
              twice the specified rate.

       controller_burst_limit: optional integer, at least 25
              In conjunction with controller_rate_limit, the maximum number of
              unused  packet credits that the bridge will allow to accumulate,
              in packets.  If not specified, the  default  is  implementation-
              specific.