Re: [v6ops] control and security of DHCP

[Owen DeLong <[e-mail]>]

On Jan 14, 2014, at 11:23 , Ray Hunter <[e-mail]> wrote:

>> Owen DeLong <mailto:[e-mail]>
>> 14 January 2014 19:17
>> On Jan 14, 2014, at 10:11 , Ray Hunter<[e-mail]>  wrote:
>> 
>>>> Nick Hilliard<mailto:[e-mail]>
>>>> 14 January 2014 18:21
>>>> 
>>>> private vlans are troublesome, to say the least. In a virtualised
>>>> environment, you need multi-switch support for specific types of pvlans.
>>>> This places vendor restrictions on the types of kit you need to deploy.
>>>> 
>>>> Nick
>>>> ------------------------------------------------------------------------
>>> Yes.
>>> 
>>> I've read posts from a number of DC operators who have expressly chosen for PVLANs compared to deploying dedicated L3 ports per server/ customer in multi-tenant environments, driven by a desire to save on very scarce public IPv4 addresses.
>> 
>> Which might make sense when the customers are on separate hardware.
> Agreed. But if you can emulate a L2 LAN, or a L3 router, you can presumably also emulate a PVLAN.

That doesn't necessarily follow, actually. At least in Linux, to the best of my knowledge, it's easy to set up multiple bridge groups, route between them and connect your virtual hosts accordingly. I don't know of any way to set up PVLAN emulation.

OTOH, I've always regarded PVLAN as a really horrible hackish technique for IPv4 address conservation where segmentation would be the preferred solution, so I can't imagine preferring a PVLAN solution when a VLAN solution is available unless I'm stuck in IPv4 land and short on addresses.

>> When the customers are separate virtuals on the same hardware, PVLANs become a bit less useful, though at that point, dedicated L3 ports in the virtual switch on the host become much more feasible, though you still have the network addressing cost issue if you're tied to IPv4.
> Right..
>>> That of course will likely bring problems migrating to IPv6 in the future e.g. DAD is probably not going to be able to detect duplicate addresses via multicast.
>> 
>> Depends on how the PVLANs treat link-scoped IPv6 multicast.
> Yes. There's no standard AFAIK.

There are no standards for PVLANs at all to the best of my knowledge. I suspect each vendor has a subtly different implementation and definition of the term to begin with. They're simply a terrible terrible hack that makes sense only in the context of extreme address shortage.

>> 
>>> Hence my suggestion of prefix length>>  64 + PVLAN + DHCPv6 + DHCPv6 setting default router + HSRPv6/VRRPv3 to exactly mirror the IPv4 setup.
>> 
>> Not sure how that really helps. Why is a longer prefix length allegedly useful in this context?
>> 
>> Owen
>> 
>> 
> The context of this thread was a request for DHCPv6 to be able to set the default router, and avoid using RA.
> That's an interesting topic.

Still not understanding how the longer prefix helps with that.

> 
> I'm happy to continue the discussion about prefix length in detail, but shall we do that another time?
> 
> Is it sufficient for now to say that in a virtual environment, I think it's even more important to contain resource depletion problems and potential cross-contamination between environments? The memory used to contain e.g. an ND table on one virtual LAN switch or router is almost certainly allocated from a shared pool that may not be well protected from overflowing. And it's going to be very easy to fill up the TCP session tables in e.g. machine firewalls using ip6tables, if a single rogue source on the local DC LAN can spoof source addresses from the equivalent of an entire continent today.

I still don't see the cost benefit ratio of such attacks being such that they are all that likely to occur. There are easy enough ways to commit such attacks in IPv4, yet they remain quite rare. I don't see any reason they would increase in IPv6. They are high risk, low reward types of attacks.

Owen