Open Stack

Hi Xuhan,

I agree that such subnet shouldn’t be allowed to be added in a neutron router.

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?

thanks,
Robert



On 4/25/14, 5:46 AM, "Xuhan Peng" <pengxuhan at gmail.com<mailto:pengxuhan at gmail.com>> wrote:

Sean and Robert,

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:

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.

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.

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.

Thoughts?  If we all agree, I will open a bug to disallow subnet with gateway outside CIDR be attached to a router.

Xuhan


On Wed, Mar 26, 2014 at 9:52 PM, Robert Li (baoli) <baoli at cisco.com<mailto:baoli at cisco.com>> wrote:
Hi Sean,

Unless I have missed something, this is my thinking:
  -- I understand that the goal is to allow RAs from designated sources
only.
  -- initially, xuhanp posted a diff for
https://review.openstack.org/#/c/72252. And my comment was that subnet
that was created with gateway ip not on the same subnet can't be added
into the neutron router.
  -- as a result, https://review.openstack.org/#/c/76125/ was posted to
address that issue. With that diff, LLA would be allowed. But a
consequence of that is a gateway port would end up having two LLAs: one
that is automatically generated, the other from the subnet gateway IP.
  -- with xuhanp's new diff for https://review.openstack.org/#/c/72252, if
openstack native RA is enabled, then the automatically generated LLA will
be used; and if it's not enabled, it will use the external gateway's LLA.
And the diff seems to indicate this LLA comes from the subnet's gateway
IP.
  -- Therefore, the change of https://review.openstack.org/#/c/76125/
seems to be able to add the gateway IP as an external gateway.
  -- Thus, my question is: should such a subnet be allowed to add in a
router? And if it should, what would the semantics be? If not, proper
error should be provided to the user. I'm also trying to figure out the
reason that such a subnet needs to be created in neutron (other than
creating L2 ports for VMs).

-- Another thought is that if the RA is coming from the provider net, then
the provider net should have installed mechanisms to prevent rogue RAs
from entering the network. There are a few RFCs that address the rogue RA
issue.

see inline as well.

I hope that I didn't confuse you guys.

Thanks,
Robert


On 3/25/14 2:18 PM, "Collins, Sean" <Sean_Collins2 at cable.comcast.com<mailto:Sean_Collins2 at cable.comcast.com>>
wrote:

>During the review[0] of the patch that only allows RAs from known
>addresses, Robert Li brought up a bug in Neutron, where a
>IPv6 Subnet could be created, with a link local address for the gateway,
>that would fail to create the Neutron router because the IP address that
>the router's port would be assigned, was a link local
>address that was not on the subnet.
>
>This may or may have been run before force_gateway_on_subnet flag was
>introduced. Robert - if you can give us what version of Neutron you were
>running that would be helpful.

[Robert] I'm using the latest


>
>Here's the full text of what Robert posted in the review, which shows
>the bug, which was later filed[1].
>
>>> This is what I've tried, creating a subnet with a LLA gateway address:
>
>>> neutron subnet-create --ip-version 6 --name myipv6sub --gateway
>>>fe80::2001:1 mynet 2222:3333::/64
>>>
>>> Created a new subnet:
>>>
>>>+------------------+----------------------------------------------------
>>>----------------+
>>> | Field | Value |
>>>
>>>+------------------+----------------------------------------------------
>>>----------------+
>>> | allocation_pools | {"start": "2222:3333::1", "end":
>>>"2222:3333::ffff:ffff:ffff:fffe"} | | cidr | 2222:3333::/64 | |
>>>dns_nameservers | | | enable_dhcp | True | | gateway_ip | fe80::2001:1
>>>| | host_routes | | | id | a1513aa7-fb19-4b87-9ce6-25fd238ce2fb | |
>>>ip_version | 6 | | name | myipv6sub | | network_id |
>>>9c25c905-da45-4f97-b394-7299ec586cff | | tenant_id |
>>>fa96d90f267b4a93a5198c46fc13abd9 |
>>>
>>>+------------------+----------------------------------------------------
>>>----------------+
>>>
>>> openstack at devstack-16:~/devstack$ neutron router-list
>
>>>
>>>+--------------------------------------+---------+----------------------
>>>-------------------------------------------------------+
>>> | id | name | external_gateway_info
>>> |
>>>+--------------------------------------+---------+----------------------
>>>-------------------------------------------------------+
>>> | 7cf084b4-fafd-4da2-9b15-0d25a3e27e67 | router1 | {"network_id":
>>>"02673c3c-35c3-40a9-a5c2-9e5c093aca48", "enable_snat": true}
>>> |
>>>
>>>+--------------------------------------+---------+----------------------
>>>-------------------------------------------------------+
>>>
>>> openstack at devstack-16:~/devstack$ neutron router-interface-add
>>>7cf084b4-fafd-4da2-9b15-0d25a3e27e67 myipv6sub
>>>
>>> 400-{u'NeutronError': {u'message': u'Invalid input for operation: IP
>>>address fe80::2001:1 is not a valid IP for the defined subnet.',
>>>u'type': u'InvalidInput', u'detail': u''}}
>>>
>
>During last week's meeting, we had a bit of confusion near the end of the
>meeting[2] about the following bug, and the fix[3].
>
>If I am not mistaken - the fix is so that when you create a v6 Subnet
>with a link local address, then create a Neutron router to serve as the
>gateway for that subnet - the operation will successfully complete and a
>router will be created.
>
>We may need to take a look at the code that create a router - to ensure
>that only one gateway port is created, and that the link local address
>from the subnet's 'gateway' attribute is used as the address.

[Robert] We are discussing what's going to happen when such a subnet is
added into a router. The neutron router may have already existed.


>
>This is at least my understanding of the problem as it stands today -
>and that this bug and fix does not involve any external gateways or
>physical devices that Neutron does not control - this is exclusively
>about Neutron routers.
>
>
>[0]: https://review.openstack.org/#/c/72252/
>
>[1]: https://bugs.launchpad.net/neutron/+bug/1284518
>
>[2]:
>http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.201
>4-03-18-14.02.log.html
>
>[3]: https://review.openstack.org/#/c/76125/
>
>
>--
>Sean M. Collins
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140508/b0bf624d/attachment.html>