> > Dacheng: No. In the security requirement work, the control/plane >protection between NVEs and hypervisors are discussed. > [Zu Qiang] this is how it is confused. In the draft you have a statement that " Attacks from malicious TSes " and here you explained it means an attack on the NVE-hypervisor control plane from a compromised hypervisor. Those are two different kind attacks. In the draft you have both compromised hypervisor and compromised VM defined as compromised TS. Please make it correct! I guess what you mean is that a compromised TS may try to intercept the NVE-hypervisor control packet. Or an attacker may use the compromised hypervisor to attack the NVE control plane. Please make it clear in the draft.
Dacheng: Ok, in the last version, we didn't try to explicitly distinguish the attacks which a melicious VM which tried to perfrom attakers by compromising its hypervisor from the attacks raised from compromised hypervisor. I will think about this. [Zu Qiang] ARP or ND are sent in the TS data plane. A good implementation is that the NVE will only need to query the NVA for the first ARP message. Or it does not need to query the NVA in the push model. So how the faked ARP can flood the NVE-NVA control signalling? Normally a good NVE implementation shall have some kind firewall function on the TS data traffic to drop any DOS type data plane traffic. This can avoid any flood on NVE-NVE data plane. Unless you want to add TS data plane FW requirement in the NVE, otherwise I don't see any new security issue here. Dacheng: Let's assume a scenario. An attacker generates large amount of fake ARP packet to query different non-existing hosts. In this case, when a NVE receive an ARP request which it does not know the answer, it may try to consult NVA, which may result DoS attacks. So, the capability of filtering the first packet is not sufficient here. We all know there are various way to deal with this type of attack. But we cannot say there is no security issue, right? _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
