James Carlson wrote:
> Erik Nordmark wrote:
>> James Carlson wrote:
>>
>>> The problem, though, is that the MAC layer knows nothing of DHCP
>>> client IDs. It can't know a priori which ones are valid, invalid, or
>>> otherwise.
>> Hence the notion that the dhcpnospoof property would be configured with
>> the allowed MAC address and/or client ID on a per vnic basis.
>
> The allowed MAC address is already part of the VNIC configuration, isn't
> it? It should just be the client ID (if any) that's at issue.
Having dhcpnospoof default to using the same MAC address for both checks
definitely makes sense. I'm not sure it should be impossible to specify
a different MAC address to check for the source address field in the MAC
header, and the chaddr in the bootp/dhcp packet.
> I think that parameter probably going to be tough to manage for any site
> that actually uses client IDs. They're meant to be a bit more ad-hoc.
Agreed. It might be that client IDs aren't that useful in a virtualized
network.
> Maybe the DHCP authentication option needs to be revived.
Doesn't that just move the problem to a key management problem?
AFAIU each domU would need to have a different key for the DHCP server
to be able to securely tell them apart using DHCP authentication.
>> But the DHCP server or relay out on the Ethernet doesn't know which domU
>> sent the DHCP packet.
>
> It does know which MAC address sent it, and in the cases we've been
> talking about, that address identifies the domU.
The DHCP server only knows the chaddr AFAIK. The DHCP server
implementation doesn't have access to the MAC header thus it can't check
that the chaddr matches the MAC source address.
Erik
