A comment on the issue of trusting the TS From: Larry Kreeger (kreeger) [mailto:[email protected]] Sent: Friday, August 30, 2013 6:43 PM To: Zu Qiang; [email protected]<mailto:[email protected]>; Thomas Narten; Black, David Subject: Re: Comment on draft-kreeger-nvo3-hypervisor-nve-cp-01
Hi Zu, See my responses inline. - Larry From: Zu Qiang <[email protected]<mailto:[email protected]>> Date: Friday, August 30, 2013 12:30 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Larry Kreeger <[email protected]<mailto:[email protected]>>, Thomas Narten <[email protected]<mailto:[email protected]>>, David Black <[email protected]<mailto:[email protected]>> Subject: Comment on draft-kreeger-nvo3-hypervisor-nve-cp-01 * 4.2: The two ways of TS address discovery is for MAC address discovery? IP address discovery or both? Do we allow the VM to inform the NVE directly at VN address association? Can we cover it in the text as well? LK> Our goal is the make the implementation of the VN completely hidden from the TS (VM). There should be no requirement to modify the TS to participate in address advertisement. There is also an issue of trust, we should try to avoid trusting a TS to advertise its address. [Zu Qiang] I do agree the impacts on TS shall be avoided. But why the TS address advertisement is untrusted? For instance, if the NVE is playing the role of subnet GW, is it allowed that a VM may send ARP message to advertise its address? If TS address advertisement is untrusted, then the TS cannot be trusted, meaning the data plane gleaning is also untrusted, right? LK2> IMO, whether to glean source addresses emitted by the TS would be a policy decision enforced by the entity the TSI connects to. For example, in the case of a VM, the hypervisor often knows the IP address assigned to the TSI by the orchestration system and can choose to drop any packets with source addresses that do not match it. Alternatively, the policy could be to glean addresses, but place a limit on how many to prevent a DOS attack. PAT> It is common for the hypervisor (or the NIC when the VM sends directly to it as in SR-IOV) to check at least the MAC address and VLAN ID (or to add the VLAN tag for a VM that sends untagged). The VM shouldn't be trusted for information that is used to determine the VN at the NVE. If the TS was trusted for that, one wouldn't be providing reliable isolation between the VNs. Perhaps in some cases policy would trust a VM TS for that information, but we need to provide for common case where the VM TS isn't trusted to declare what VN it belongs to.
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
