<div dir="ltr"><p dir="ltr">On Mon, Jun 8, 2015 at 3:52 PM, Kevin Benton <<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>> wrote:<br>
> There is a bug in security groups here:<br>
> <a href="https://bugs.launchpad.net/neutron/+bug/1359523" target="_blank">https://bugs.launchpad.net/neutron/+bug/1359523</a><br>
><br>
> In the example scenario, it's caused by conntrack zones not being isolated.<br>
> But it also applies to the following scenario that can't be solved by zones:<br>
><br>
> create two networks with same <a href="http://10.0.0.0/24" target="_blank">10.0.0.0/24</a><br>
> create port1 in SG1 on net1 with IP 10.0.0.1<br>
> create port2 in SG1 on net2 with IP 10.0.0.2<br>
> create port3 in SG2 on net1 with IP 10.0.0.2<br>
> create port4 in SG2 on net2 with IP 10.0.0.1</p>
<p dir="ltr">This sounds like a different bug than 1359523. It isn't what was described in the bug report and has a different underlying cause. While it looks similar on the surface, could we open up a new bug to track this? Just curious has anyone hit this in the wild or is this totally contrived?</p>
<p dir="ltr">My first reaction to this is that if you set this up like this, you deserve it. Maybe we just advise that people plan to avoid scenarios that intersect multiple security groups across disparate L2 networks using overlapping IP address space. Don't use overlapping subnets. Or, if you do, don't use the same security group across them. But, that is just a cop out if we haven't had a discussion.</p><p>Using address scopes will prevent any overlap and fix this situation in the following way. I think this is what Kevin had in mind:</p><p>create two networks with same <a href="http://10.0.0.0/24" target="_blank">10.0.0.0/24</a> allocating the subnets from an address pool. They must be allocated from different subnet scopes. We know because if they were the same scope, overlap wouldn't be allowed. A fundamental design feature of address scopes is that address overlap is prevented within the scope.</p><p> Net1 has address scope a and net2 has address scope b. All the subnets on a network from the same address family are required to be from the same pool. Hence, they'll be in the same scope.</p><p> create port1 in SG1 on net1 with IP 10.0.0.1. Has address scope a<br> create port2 in SG1 on net2 with IP 10.0.0.2. Has address scope b<br> create port3 in SG2 on net1 with IP 10.0.0.2. Has address scope a<br> create port4 in SG2 on net2 with IP 10.0.0.1. Has address scope b<br></p><p>The scope names are arbitrary and contrived but we know that port1 and port3 must be in the same scope because they are on the same network. We also know that a != b because the same scope wouldn't allow the overlap.</p>
<p dir="ltr">> port1 can communicate with port3 because of the allow rule for port2's IP<br>
> port2 can communicate with port4 because of the allow rule for port1's IP<br><br>These would be prevented if the security group code notices that port1 and port2 are not in the same scope and therefore will never be able to communicate without some sort of NAT in between. It should leave out the allow rules because of this.</p><p dir="ltr">Same for port3 and port4 in the other SG.<br></p><p dir="ltr">
> The solution will require the security groups processing code to understand<br>
> that a member of a security group is not actually reachable by another<br>
> member and skip the allow rule for that member.<br></p><p>I said the same thing just with a little more specificity and referring to the example.</p><p>> With the current state of things, it will take a tone of kludgy code to<br>> check for routers and router interfaces to see if two IPs can communicate<br>> without NAT. However, if we end up with the concept of address-scopes, it<br>> just becomes a simple address scope comparison.<br><br>I'm not inclined to invest a lot of effort in to this. I don't see it as a big security hole. Is there a way to exploit this that I cannot see? I'm still inclined to say that we should come up with some kind of advise for how to manage SGs and networks to avoid it.<br><br>> Implement address scopes.</p>
<p dir="ltr">I will. Stay tuned. I did not, however, include any kind of integration with security groups with my address scopes spec. I don't think I should necessarily stop everything to include it either. I still tend to think that this example is a bit contrived which is why I've asked if this was hit in the wild.</p><p dir="ltr">You should keep in mind that address scopes will not be forced on anyone. You will get the same thing as today if you continue to make all the same API calls to set it up. Address scopes will only come in to play if you use subnet pools. If you don't use subnet pools, you can still create overlapping address ranges. So, we can make security groups address scope aware but it won't fix the problem for existing models.<br></p>
<p dir="ltr">Carl</p>
</div>