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

[[e-mail]]

Hi, Luyuan

I agree with this text "If the end-system and NVE belongs to the same DC 
operator, then the end-system is in the trusted zone of the operator."
For a another case, for example, end-system and NVE belongs to the 
DIFFERENT DC operator, how can we define the trust zone?

-----------
Yinxing Wei
 



"Luyuan Fang (lufang)" <[e-mail]> 
·¢¼þÈË:  [e-mail]
2012/07/11 11:27

ÊÕ¼þÈË
"Larry Kreeger (kreeger)" <[e-mail]>, "[e-mail]" 
<[e-mail]>, "[e-mail]" 
<[e-mail]>, "[e-mail]" <[e-mail]>
³­ËÍ

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






Agree with Larry. It is the end-system talking VDP with the NVE.  If the 
end-system and NVE belongs to the same DC operator, then the end-system is 
in the trusted zone of the operator.
 
A different point on l3, if it is L3 overlay tunnel starting at the 
end-system, I¡¯d assume no VDP involvement.
 
Luyuan
 
From: [e-mail] [mailto:[e-mail]] On Behalf Of 
Larry Kreeger (kreeger)
Sent: Tuesday, July 10, 2012 11:07 PM
To: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [nvo3] TES-NVE attach/detach protocol security 
(mobility-issues draft)
 
Trying to clarify the discussion below¡­using the terminology from 
draft-lasserre-nvo3-framework-03
 
A TES (tenant end system) is not a trusted entity and would not use VDP to 
communicate to an NVE.  It is an "End System" that would use VDP to 
communicate to an NVE, which would be a trusted device within the data 
center that is administered by the data center operator ¨C NOT a tenant.
 
 - Larry
 
From: David Black <[e-mail]>
Date: Tuesday, July 10, 2012 9:27 AM
To: "[e-mail]" <[e-mail]>, "[e-mail]" <
[e-mail]>
Subject: Re: [nvo3] TES-NVE attach/detach protocol security 
(mobility-issues draft)
 
Linda,
 
We¡¯re mostly in agreement ...
 
IEEE802.1 Qbg¡¯s VDP doesn¡¯t do encapsulation, so it is different from 
NVo3¡¯s NVE. VDP allows the hypervisor to notify the network of the 
virtual network  to which the new VMs belong. In that aspect, there is 
similarity to NVo3¡¯s NVE. 
 
Right - VDP is a protocol that can be used between TES and NVE.  For a 
hypervisor, VDP would only be used on a link to an external NVE (e.g., in 
the ToR switch).  If the NVE is inside the hypervisor there¡¯s no external 
TES-NVE protocol because both the TES and NVE are in the same physical 
server.
 
Hypervisor may be trusted, but  I don¡¯t think DC operators can trust VMs.
 
I agree, and VDP approaches this via use of a link-local destination MAC 
address for all VDP frames sent to the NVE.  If a VM sends a VDP frame, 
that frame is received by a virtual switch in the hypervisor, and so a 
simple solution is for virtual switches to drop and ignore all VDP frames 
sent by VMs.  An SR-IOV NIC would be configured to do likewise for VDP 
frames sent by VMs.  In both cases, this enables an external NVE in a ToR 
switch to rely on the VDP frames it receives having been originated by the 
hypervisor and not the VMs.
 
Security will be a big concern for any protocols from TES to NVE. 
 
I agree, and any IP based TES-NVE protocol will be unable to rely on 
link-local destination MACs, hence I would expect authentication to be at 
least a ¡°MUST implement¡± requirement if an IP-based protocol is used.
 
Thanks,
--David
 
From: Linda Dunbar [mailto:[e-mail]] 
Sent: Tuesday, July 10, 2012 11:49 AM
To: Black, David; [e-mail]
Subject: RE: TES-NVE attach/detach protocol security (mobility-issues 
draft)
 
David, 
 
IEEE802.1 Qbg¡¯s VDP doesn¡¯t do encapsulation, so it is different from 
NVo3¡¯s NVE. VDP allows the hypervisor to notify the network of the 
virtual network  to which the new VMs belong. In that aspect, there is 
similarity to NVo3¡¯s NVE. 
 
Hypervisor may be trusted, but  I don¡¯t think DC operators can trust VMs. 
When VMs are instantiated with applications from random clients, whose 
applications can initiate attack to other clients network. It happened 
once in Amazon¡¯s EC2. 
Security will be a big concern for any protocols from TES to NVE. 
 
Linda
 
From: [e-mail] [mailto:[e-mail]] 
Sent: Tuesday, July 10, 2012 8:17 AM
To: Linda Dunbar; [e-mail]
Subject: TES-NVE attach/detach protocol security (mobility-issues draft)
 
Hi Linda,
 
[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 don¡¯t think so.  If the NVE is in the hypervisor, the external Ethernet 
switches (bridges) don¡¯t see the inner MACs after encapsulation, hence 
VDP to the external Ethernet switch (bridge) is not useful because it sets 
up inner MACs that won¡¯t occur in the outer headers beyond the hypervisor
¡¯s NVE.  If the NVE is in the external Ethernet switch (bridge), VDP is 
useful because then it¡¯s running between the TES and the NVE.
 
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.
 

 
 
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
 _______________________________________________
nvo3 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/nvo3