<div dir="ltr"><div><div>Robert,<br><br></div>I have plan to file a BP to add egress rule to stop RA sending from VM. However, we will still need rules to dropped rogue RA for provider network RA, right? There is no other ways we can tell which RA is legitimate from OpenStack's perspective except using the LLA gateway provided by network admin.<br>
<br></div><div>Thoughts?<br></div><div><br></div>Xuhan<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 8, 2014 at 8:22 PM, Robert Li (baoli) <span dir="ltr"><<a href="mailto:baoli@cisco.com" target="_blank">baoli@cisco.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>Hi Xuhan,</div>
<div><br>
</div>
<div>I agree that such subnet shouldn’t be allowed to be added in a neutron router.</div>
<div><br>
</div>
<div>However, I have some reservations in creating a subnet with an external LLA gateway address. First of all, it seems that the sole purpose of providing the gateway IP is to install an RA rule to permit RAs from that gateway. Secondly, what if the gateway
IP needs to be changed? Would that incur updates in the neutron subnets that refer to it? I think that we need a better strategy for RA spoofing. Currently, rogue RAs are dropped at the receiving end. Would it be better to stop them at the source and to allow
RAs being SENT from the legitimate sources only?</div>
<div><br>
</div>
<div>thanks,</div>
<div>Robert</div><div><div class="h5">
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<span>
<div>
<div>On 4/25/14, 5:46 AM, "Xuhan Peng" <<a href="mailto:pengxuhan@gmail.com" target="_blank">pengxuhan@gmail.com</a>> wrote:</div>
</div>
<div><br>
</div>
<blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
<div>
<div>
<div dir="ltr">Sean and Robert,<br>
<br>
Sorry for replying this late, but after giving this a second thought, I think it makes sense to not allow a subnet with a LLA gateway IP address to be attached to a neutron router for the following reasons:<br>
<br>
1. A subnet with LLA address gateway specified is only used to receive RA from provider router. I could not think of any other use case that a user want to specify LLA address gateway for an Neutron subnet.<br>
<br>
2. Attach a subnet with LLA (or even any address outside subnet's cidr) will cause the port have two LLA (or another address outside subnet's cidr) on the subnet gateway port (qr-XXXX). This will confuse dnsmasq about binding with which address.<br>
<br>
3. For allowing RA sending from dnsmasq on gateway port, we can use ip command to get the LLA. Currently I use calculation method to get the source address, but I will improve it to use ip command to make sure the source IP is right.<br>
<br>
Thoughts? If we all agree, I will open a bug to disallow subnet with gateway outside CIDR be attached to a router.<br>
<br>
Xuhan<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Mar 26, 2014 at 9:52 PM, Robert Li (baoli) <span dir="ltr">
<<a href="mailto:baoli@cisco.com" target="_blank">baoli@cisco.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Sean,<br>
<br>
Unless I have missed something, this is my thinking:<br>
-- I understand that the goal is to allow RAs from designated sources<br>
only.<br>
-- initially, xuhanp posted a diff for<br>
<a href="https://review.openstack.org/#/c/72252" target="_blank">https://review.openstack.org/#/c/72252</a>. And my comment was that subnet<br>
that was created with gateway ip not on the same subnet can't be added<br>
into the neutron router.<br>
-- as a result, <a href="https://review.openstack.org/#/c/76125/" target="_blank">
https://review.openstack.org/#/c/76125/</a> was posted to<br>
address that issue. With that diff, LLA would be allowed. But a<br>
consequence of that is a gateway port would end up having two LLAs: one<br>
that is automatically generated, the other from the subnet gateway IP.<br>
-- with xuhanp's new diff for <a href="https://review.openstack.org/#/c/72252" target="_blank">
https://review.openstack.org/#/c/72252</a>, if<br>
openstack native RA is enabled, then the automatically generated LLA will<br>
be used; and if it's not enabled, it will use the external gateway's LLA.<br>
And the diff seems to indicate this LLA comes from the subnet's gateway<br>
IP.<br>
-- Therefore, the change of <a href="https://review.openstack.org/#/c/76125/" target="_blank">
https://review.openstack.org/#/c/76125/</a><br>
seems to be able to add the gateway IP as an external gateway.<br>
-- Thus, my question is: should such a subnet be allowed to add in a<br>
router? And if it should, what would the semantics be? If not, proper<br>
error should be provided to the user. I'm also trying to figure out the<br>
reason that such a subnet needs to be created in neutron (other than<br>
creating L2 ports for VMs).<br>
<br>
-- Another thought is that if the RA is coming from the provider net, then<br>
the provider net should have installed mechanisms to prevent rogue RAs<br>
from entering the network. There are a few RFCs that address the rogue RA<br>
issue.<br>
<br>
see inline as well.<br>
<br>
I hope that I didn't confuse you guys.<br>
<br>
Thanks,<br>
Robert<br>
<br>
<br>
On 3/25/14 2:18 PM, "Collins, Sean" <<a href="mailto:Sean_Collins2@cable.comcast.com" target="_blank">Sean_Collins2@cable.comcast.com</a>><br>
wrote:<br>
<div><br>
>During the review[0] of the patch that only allows RAs from known<br>
>addresses, Robert Li brought up a bug in Neutron, where a<br>
>IPv6 Subnet could be created, with a link local address for the gateway,<br>
>that would fail to create the Neutron router because the IP address that<br>
>the router's port would be assigned, was a link local<br>
>address that was not on the subnet.<br>
><br>
>This may or may have been run before force_gateway_on_subnet flag was<br>
>introduced. Robert - if you can give us what version of Neutron you were<br>
>running that would be helpful.<br>
<br>
</div>
[Robert] I'm using the latest<br>
<div>
<div><br>
<br>
><br>
>Here's the full text of what Robert posted in the review, which shows<br>
>the bug, which was later filed[1].<br>
><br>
>>> This is what I've tried, creating a subnet with a LLA gateway address:<br>
><br>
>>> neutron subnet-create --ip-version 6 --name myipv6sub --gateway<br>
>>>fe80::2001:1 mynet 2222:3333::/64<br>
>>><br>
>>> Created a new subnet:<br>
>>><br>
>>>+------------------+----------------------------------------------------<br>
>>>----------------+<br>
>>> | Field | Value |<br>
>>><br>
>>>+------------------+----------------------------------------------------<br>
>>>----------------+<br>
>>> | allocation_pools | {"start": "2222:3333::1", "end":<br>
>>>"2222:3333::ffff:ffff:ffff:fffe"} | | cidr | 2222:3333::/64 | |<br>
>>>dns_nameservers | | | enable_dhcp | True | | gateway_ip | fe80::2001:1<br>
>>>| | host_routes | | | id | a1513aa7-fb19-4b87-9ce6-25fd238ce2fb | |<br>
>>>ip_version | 6 | | name | myipv6sub | | network_id |<br>
>>>9c25c905-da45-4f97-b394-7299ec586cff | | tenant_id |<br>
>>>fa96d90f267b4a93a5198c46fc13abd9 |<br>
>>><br>
>>>+------------------+----------------------------------------------------<br>
>>>----------------+<br>
>>><br>
>>> openstack@devstack-16:~/devstack$ neutron router-list<br>
><br>
>>><br>
>>>+--------------------------------------+---------+----------------------<br>
>>>-------------------------------------------------------+<br>
>>> | id | name | external_gateway_info<br>
>>> |<br>
>>>+--------------------------------------+---------+----------------------<br>
>>>-------------------------------------------------------+<br>
>>> | 7cf084b4-fafd-4da2-9b15-0d25a3e27e67 | router1 | {"network_id":<br>
>>>"02673c3c-35c3-40a9-a5c2-9e5c093aca48", "enable_snat": true}<br>
>>> |<br>
>>><br>
>>>+--------------------------------------+---------+----------------------<br>
>>>-------------------------------------------------------+<br>
>>><br>
>>> openstack@devstack-16:~/devstack$ neutron router-interface-add<br>
>>>7cf084b4-fafd-4da2-9b15-0d25a3e27e67 myipv6sub<br>
>>><br>
>>> 400-{u'NeutronError': {u'message': u'Invalid input for operation: IP<br>
>>>address fe80::2001:1 is not a valid IP for the defined subnet.',<br>
>>>u'type': u'InvalidInput', u'detail': u''}}<br>
>>><br>
><br>
>During last week's meeting, we had a bit of confusion near the end of the<br>
>meeting[2] about the following bug, and the fix[3].<br>
><br>
>If I am not mistaken - the fix is so that when you create a v6 Subnet<br>
>with a link local address, then create a Neutron router to serve as the<br>
>gateway for that subnet - the operation will successfully complete and a<br>
>router will be created.<br>
><br>
>We may need to take a look at the code that create a router - to ensure<br>
>that only one gateway port is created, and that the link local address<br>
>from the subnet's 'gateway' attribute is used as the address.<br>
<br>
</div>
</div>
[Robert] We are discussing what's going to happen when such a subnet is<br>
added into a router. The neutron router may have already existed.<br>
<div>
<div><br>
<br>
><br>
>This is at least my understanding of the problem as it stands today -<br>
>and that this bug and fix does not involve any external gateways or<br>
>physical devices that Neutron does not control - this is exclusively<br>
>about Neutron routers.<br>
><br>
><br>
>[0]: <a href="https://review.openstack.org/#/c/72252/" target="_blank">https://review.openstack.org/#/c/72252/</a><br>
><br>
>[1]: <a href="https://bugs.launchpad.net/neutron/+bug/1284518" target="_blank">https://bugs.launchpad.net/neutron/+bug/1284518</a><br>
><br>
>[2]:<br>
><a href="http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.201" target="_blank">http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.201</a><br>
>4-03-18-14.02.log.html<br>
><br>
>[3]: <a href="https://review.openstack.org/#/c/76125/" target="_blank">https://review.openstack.org/#/c/76125/</a><br>
><br>
><br>
>--<br>
>Sean M. Collins<br>
>_______________________________________________<br>
>OpenStack-dev mailing list<br>
><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</span>
</div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>