Re: [nvo3] TES-NVE attach/detach protocol security (mobility-issues draft)

[Xuxiaohu <[e-mail]>]

As per the definition in 802.1Qbg, “…When ECP is used as a transport protocol for VDP, ECP uses the Nearest Customer Bridge group MAC
address (Table 8-1) as the destination address for ECPDUs…” Hence if the blade switch is not enabled with 802.1D, it should still be able to transparently forward the VDP packets as if they were normal MAC frames received from the default VLAN, just like it could transparently forward the BPDU frame which also uses the Nearest Customer Bridge group MAC address(i.e., 01-80-C2-00- 00-00) as the destination MAC address.

Best regards,
Xiaohu

发件人: [e-mail] [mailto:[e-mail]] 代表 Stiliadis, Dimitrios (Dimitri)
发送时间: 2012年7月11日 1:03
收件人: [e-mail]; [e-mail]
主题: Re: [nvo3] TES-NVE attach/detach protocol security (mobility-issues draft)

David:

Blade systems, where the NVE is the ToR is one example where this gets messy. Traffic
goes from the blades to an L2 switch to the ToR, and some people also want to offer
bare metal as a service in such systems.

Cheers,

Dimitri





From: [e-mail] [mailto:[e-mail]]
Sent: Tuesday, July 10, 2012 9:34 AM
To: Stiliadis, Dimitrios (Dimitri); [e-mail]
Subject: RE: [nvo3] TES-NVE attach/detach protocol security (mobility-issues draft)

Dimitri,

VDP is always sent to a link-local MAC; bridges/switches don’t forward VDP frames.  If one can rely on the hypervisor being correctly configured (e.g., virtual switches receive, drop and ignore VDP frames sent by VMs), and link integrity can also be relied upon (e.g., no injection of VDP frames), the ToR switch that receives a VDP frame can safely assume that the hypervisor sent it.

If either of those elements cannot be relied upon, or the NVE needs to be located further away from the TES than the other end of the same Ethernet link, then something else in the way of authentication would be needed.

Thanks,
--David

From: Stiliadis, Dimitrios (Dimitri) [mailto:[e-mail]]
Sent: Tuesday, July 10, 2012 11:27 AM
To: Black, David; [e-mail]; [e-mail]
Subject: RE: [nvo3] TES-NVE attach/detach protocol security (mobility-issues draft)

David,

As far as I know, VDP doesn’t have an authentication mechanism. The NVE needs to verify
that the hypervisor is who it says that it is, and same for the hypervisor. A secure solution
would have some form of authentication. This would enable greater flexibility  in the
positioning of NVEs.

Dimitri


However, it is a security hole to let TES inform NVEs of being added or deleted, unless it is in a secure environment, or NVEs (or Hypervisors) can validate the information from TES via its management system.

I’m not sure that “secure environment” sets the right expectation.

For an external NVE, it’s necessary to trust the hypervisor to provide info on VM attach/detach, so the security concern is that this info come only from the hypervisor.  For VDP this starts with use of a link-local destination MAC - if a VM sends to this MAC, the virtual switch in the hypervisor is the recipient.  That virtual switch doesn’t forward the VDP frames, and probably just drops them. For an SR-IOV NIC in the server, the virtual switch in the NIC has to drop VDP frames sent by a VM so that VDP frames originate only from the hypervisor.  If an IP-based protocol is used for this function, authentication will be needed.  For an NVE in the hypervisor, the hypervisor configures its virtual switch directly and VDP does not run outside the hypervisor.




Thanks,
--David

From: [e-mail] [mailto:[e-mail]] On Behalf Of Linda Dunbar
Sent: Monday, July 09, 2012 3:28 PM
To: Guyingjie (Yingjie); [e-mail]
Subject: Re: [nvo3] Comments on draft-dunbar-nvo3-overlay-mobility-issues

Ying Jie,

Thank you very much for the nice comments. My replies are inserted below:



From: Guyingjie (Yingjie)
Sent: Wednesday, July 04, 2012 8:15 PM
To: [e-mail]; Linda Dunbar
Subject: Comments on draft-dunbar-nvo3-overlay-mobility-issues

Hi Linda,
I read your draft on NVO3-mobility.
I am okay with most of the content, just some secondary comments on your description of mechanism between NVE and TES.
In my mind, external controller assistance is a bit more complicate to implement than using a protocol between NVEs and TES.
A premise of my comments is that NVE is on external network devices, such as TOR and EOR, and TES are VMs in physical servers.


4.1.1 First paragraph: “NVEs may
   not be aware of VMs being added or deleted unless NVEs have a north
   bound interface to a controller which can communicate with VM/server
   Manager(s).

”
This is not true. In VDP, with an Association/De-association message from Hypervisor to edge bridge(i.e. NVE in NVO3, and will use NVE instead of edge bridge in below), the bridge can be timely notified about the connect and disconnect to the bridge. That means it doesn’t need an northbound API for NVEs to be aware of VMs (dis)connection.  And also, VDP protocol can carry a field showing “This is a new created VM” or “This is a VM migrated from somewhere else”. That is VDP can fulfill the requirement of mobility notification, which can be a trigger for NVE to timely updating the states on itself, e.g. acquiring VNID associated with the VM moving/adding to the NVE, inner-outer address mapping, deleting states associated with the VM moving/deleting from this NVE.

[Linda]  In your IEEE802.1Qbg’s VDP example, the NVE would be the Hypervisor which sends Association/De-association messages to the edge bridge. I.e. the Hypervisor need to have north bound interface which is aware a VM is add or deleted.

I think that the sentence should have stated as “NVEs may not be aware of the VMs being added or deleted unless NVEs have a north bound interface to a controller which can communicate with VM/Server managers, or there is a protocol between TES and NVEs as defined by IEEE802.1Qbg.

However, it is a security hole to let TES inform NVEs of being added or deleted, unless it is in a secure environment, or NVEs (or Hypervisors) can validate the information from TES via its management system.



In the 4th paragraph of 4.1.1, If, for whatever reason, it is necessary to have local VID in the

   data frames before encapsulating outer header of EgressNVE-DA/

   IngressNVE-SA /VNID, NVE should get the specific local VID from the

   external Controller for those untagged data frames coming to each

   Virtual Access Point
For some reasons, I don’t think this part is good.
First, there is other way to get the local VID except for external controller. In VDP, when NVE receives a (Pre)Association message from TES, it can acquire local VID from a Database which is managed by network administrator.
[Linda] Yes, I should have added that NVE can also get local VID from TES as IEEE802.1Qbg defined.


Secondly, while defining VDP, we consider of the situation you described, i.e. different local VID at different location. So the VDP can support different local VID under different NVE, by getting local VID from Database while receive the (Pre)Association message. And it can even feedback to the Hypervisor, so that the data frames from TES could have the local VID on it, but it’s also okay for NVE to add the local VID to data frames.

[Linda] it is all good if TES can have those functions. But in many environment, TES don’t. This paragraph is emphasizing on the scenario when TES don’t support IEEE802.1Qbg. It is a good idea that you point out the functions of IEEE802.1Qbg.



In the 6th paragraph in 4.1.1, The IEEE802.1Qbg's VDP protocol (Virtual Station Interface (VSI)

   discovery and configuration protocol) requires hypervisor to send VM

   profile upon a new VM is instantiated. However, not all hypervisors

   support this function.
The following is the VDP TLV definition from Qbg. Each VSI (Virtual Station Interface) usually is a VM interface id(could be MAC,IPV4/V6, UUID, etc).
The NVE gets profile from Database by VSI type & instance information. I think your profile ID also means the combination of VSI type and instance information. So we are talking the same thing.   My point is it’s not profile, but the IDs to get profile, that is carried in VDP message. It might be confusing to people knowing nothing about VDP. Carrying profile in message is a huge overload.

[cid:image001.png@01CD5917.0DBDE100]


External Controller can be very useful in NVO3, but not best suitable for each part of NVO3. I think we should think of other way for different problems.

[Linda] Thanks for sharing this table.

Linda

________________________________
Best Regards
Gu Yingjie