lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 28 Nov 2011 08:01:17 -0800
From:	Ben Pfaff <blp@...ira.com>
To:	Jamal Hadi Salim <jhs@...atatu.com>
Cc:	Herbert Xu <herbert@...dor.apana.org.au>, dev@...nvswitch.org,
	netdev@...r.kernel.org, David Miller <davem@...emloft.net>
Subject: Re: [ovs-dev] [GIT PULL v2] Open vSwitch

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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ