Re: [v6ops] control and security of DHCP

[Mark ZZZ Smith <[e-mail]>]

----- Original Message -----
> From: Ray Hunter <[e-mail]>
> To: Nick Hilliard <[e-mail]>
> Cc: "[e-mail] WG" <[e-mail]>
> Sent: Wednesday, 15 January 2014 5:11 AM
> Subject: Re: [v6ops] control and security of DHCP
> 
>>  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.
> 
> 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.
> 

Just an FYI,

Duplicate Address Detection Proxy
http://tools.ietf.org/html/rfc6957


My perspective on private VLANs etc. type problem has come from experience in the residential broadband environment with BYO CPE. Not only can't you control the type of CPE that is purchased, you can't assume that the people who operate them are capable of even the most basic security administration. It is a completely untrusted environment, and therefore I think solutions that work in that environment are also going to be quite effective in DC or enterprise environments.

These sorts of spoofing etc. problems are solved by per-subscriber PPPoE sessions, per subscriber single or double VLAN tags, or the N:1 / "private VLAN" model. All of them are isolating subscribers/CPE/hosts, however from a routing perspective the last one is the most scalable, because multiple subscribers/CPE/hosts are collected together within a single subnet (obviously we get use things such as routing aggregation to scale further, however there can still can be value in reducing FIB entries/PPPoE/QinQ session entries on the BRAS itself.)



> Hence my suggestion of prefix length >> 64 + PVLAN + DHCPv6 + DHCPv6 
> setting default router + HSRPv6/VRRPv3 to exactly mirror the IPv4 setup.
> 
> It would also mean that any failovers are likely to be very similar for 
> both IPv4 and IPv6 paths, and that HSRPv6//VRRPv3 generally has more 
> features (track/ preempt/ MD5 authentication) which RA clearly doesn't 
> have (yet), which I see as clear operational advantages. My opinion is 
> that combination is a pretty valid use case for transitioning a 
> multi-tenant IPv4 environment to IPv6 using dual stack, and which 
> requires the additional functionality you want. Otherwise people running 
> IPv4 PVLANs are going to get painted into a corner.
> 
> 
> So what security are you suggesting to deploy to ensure that your set up 
> remains sufficiently isolated between customers, even though they share 
> a L2 LAN?
> 
> I'm not saying necessarily that RA should be the only game in town, but 
> it is there today. And we all know how hard it is to prevent attacks by 
> on-link attackers (not just RA).
> 
> -- 
> Regards,
> 
> RayH
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>