CPqD/RouteFlow — pull request #4 by joestringer (2012-01-30 05:39:14+00:00)
Title: Securing RouteFlow

Per correspondence with @chesteve, I have written a couple of patches to further lock down RouteFlow.

----

*Add rule to match incoming responses to BGP connections initialised from an rfvm*

* Previously, if BGP connections were initiated from the outside, then they would be successfully passed on to the controller with a rule matching the destination port of BGP requests. *eg, packet from external router->rfvm, random source port, BGP destination port*
* However, connections initiated from inside (ie, rfvm) would cause replies to be sent with the standard BGP *source* port. *eg, rfvm->external router, quagga-specified local port, BGP destination port. The response goes external->rfvm, BGP source port, quagga-specified destination port*
* Added an extra rule to deal with this situation, forwarding to the controller as appropriate.

*Add "-s INTERFACE" option to specify whether to have traffic dropped if it is destined for the IPs on the given interface*

* When running rf-server, specify "-s *interface*" to create rules on connected datapaths, such that the default action is to drop packets that are destined for the specified controller interface.
* This action has low priority, so other rules will overwrite, eg forwarding BGP/RIP/etc
* This code assumes rf-server is running on the same box as rf-controller. rf-server has code to search through local interfaces to find the IP address that it should use for the DROP rule. If this is undesirable, then this code will need to be implemented in rf-controller. In such a case, rf-server could acquire the IP address via IPC, or rf-controller could create the rules for dropping traffic.