Forward flows may be mis-classified as return flows.

[gdecandia]

In Caddo/Folsom, for a packet going towards a VM, the security group rules are evaluated before the rule that accepts return flows. Therefore, forward flows that are admitted by the security group do NOT write connection-tracking state in the cache. (In Caddo, contrack state is kept only if isForwardFlow or isReturnFlow are evaluated during rule-processing).

As a result, the simulation of the return flow will not find contrack entries in the shared cache and will classify the flow as "forward". The return flow will keep contrack information, and that means that the original forward flow may later be mistaken for a return flow.

When might this matter? If the security group rule that allowed the forward flow (toward the VM) is removed, the flow should then be dropped. However, if it's mistakenly classified as a return flow, it will be admitted - resulting in a security hole.

The fix is be to evaluate the isReturnFlow rule before the SecurityGroup white-list.

In the longer term, MidoNet's rule API should provide a more elegant way of requesting connection-tracking on flows passing through a rule-chain. An explicit CONTRACK action instead of the side-effect of evaluating isForwardFlow/isReturnFlow.