The neighbor table attack scenario reminds me of VLAN flattening attack 
scenarios of days past - in theory you could blast a switch hard enough that 
the switch’s CPU lowers VLAN tagging priority and the network “flattens” out, 
turning switch into hub. In reality, the vendors quickly realized the situation 
as less-than-optimal and coded around it. 

This thread got me thinking of something else that might be interesting to 
think about: what about having virtual routers proxy DHCP requests[1] for v4 or 
v6? 

John
1: 
http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#DHCP_relaying

On Sep 5, 2014, at 7:52 AM, Wido den Hollander <w...@widodh.nl> wrote:

> 
> 
> On 05-09-14 12:42, Nux! wrote:
>> Hi,
>> 
>> I've been thinking about this and apparently there is a big security problem 
>> with this idea, at least my colleagues from the network dept tell me so.
>> If you want to use the router autoconfig thingy you must - as per current 
>> standards - use a /64 on the router interface and this way you expose 
>> yourself to a neighbour table attack - the neighbour table in avg cisco 
>> routers can hold tens of thousands of entries more or less, but it's still 
>> far from the trillions of addresses in a /64. This may seem far fetched but 
>> since 512k day, my colleagues don't want to take any more chances. :-)
> 
> That only works if you actually spawn thousands of instances in that subnet.
> 
> One of the things people told me that you could overflow the neighbour table 
> by sending packets to bogus IPv6 addresses.
> 
> I tried that some weeks ago on a Brocade and Extreme Networks router, but 
> they both have a system of "valid neighbours" and "pending neighbours".
> 
> Only when a neighbour actually responded it goes into the "valid" table and 
> otherwise it is kicked out of the "pending" pretty quickly.
> 
> I could not overflow any table or make them drop traffic to legitimate hosts.
> 
>> They recommend to use DHCPv6 instead with far smaller subnets, which of 
>> course complicates things quite a bit on the cloudstack side...
>> 
> 
> Well, we would still need DHCPv6 to hand out additional options like DNS, but 
> yes. Since with the subnet + MAC you can calculate which IPv6 address the 
> Instance will use based on SLAAC.
> 
> We can program that address into the security groups and that's the IPv6 
> address the guest can use.
> 
> Additional IPs is just a matter of generating a address, storing it and 
> adding it to the SG.
> 
> So Router Advertisements are a very easy option to use.
> 
>> Any thoughts?
>> 
>> Lucian
>> 
>> --
>> Sent from the Delta quadrant using Borg technology!
>> 
>> Nux!
>> www.nux.ro
>> 
>> ----- Original Message -----
>>> From: "John Kinsella" <j...@stratosec.co>
>>> To: dev@cloudstack.apache.org
>>> Sent: Wednesday, 20 August, 2014 11:59:27 PM
>>> Subject: Re: IPv6 ~ Basic Network
>>> 
>>> Please do - we started tinkering with ipv6 ages ago, never got it to
>>> production, tho.
>>> 
>>> On Aug 20, 2014, at 3:48 PM, Nux! <n...@li.nux.ro> wrote:
>>> 
>>>> Thanks Wido for the idea, then. :-)
>>>> I'll gladly share it with you guys should I come up with something that
>>>> works.
>>>> 
>>>> Lucian
>>>> 
>>>> --
>>>> Sent from the Delta quadrant using Borg technology!
>>>> 
>>>> Nux!
>>>> www.nux.ro
>>>> 
>>>> 
>>>> ----- Original Message -----
>>>>> From: "Wido den Hollander" <w...@widodh.nl>
>>>>> To: dev@cloudstack.apache.org
>>>>> Sent: Wednesday, 20 August, 2014 9:36:48 PM
>>>>> Subject: Re: IPv6 ~ Basic Network
>>>>> 
>>>>> 
>>>>> 
>>>>> On 08/20/2014 10:07 PM, Nux! wrote:
>>>>>> Wido,
>>>>>> 
>>>>>> Can you share your code for this?
>>>>>> 
>>>>> 
>>>>> Oh, I don't have any code. The setups I created have plain IPv6 without
>>>>> any security grouping.
>>>>> 
>>>>> My previous e-mail was just to illustrate what would be required.
>>>>> 
>>>>> Wido
>>>>> 
>>>>>> Cheers
>>>>>> 
>>>>>> --
>>>>>> Sent from the Delta quadrant using Borg technology!
>>>>>> 
>>>>>> Nux!
>>>>>> www.nux.ro
>>>>>> 
>>>>> 
>>> 
>>> 
>>> 

Reply via email to