Thank you, Yizhou. All of your suggestions look good and I think will be helpful in the document.
Best regards, Kathleen Sent from my mobile device > On Feb 22, 2018, at 3:52 AM, Liyizhou <liyiz...@huawei.com> wrote: > > Hi Kathleen, > > Thanks for your comments. Please see inlines with [yz]. > > Rgds, > Yizhou > > -----Original Message----- > From: Kathleen Moriarty [mailto:kathleen.moriarty.i...@gmail.com] > Sent: Thursday, February 22, 2018 12:07 PM > To: The IESG <i...@ietf.org> > Cc: draft-ietf-nvo3-hpvr2nve-cp-...@ietf.org; Matthew Bocci > <matthew.bo...@nokia.com>; nvo3-cha...@ietf.org; matthew.bo...@nokia.com; > nvo3@ietf.org > Subject: Kathleen Moriarty's No Objection on > draft-ietf-nvo3-hpvr2nve-cp-req-15: (with COMMENT) > > Kathleen Moriarty has entered the following ballot position for > draft-ietf-nvo3-hpvr2nve-cp-req-15: No Objection > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-nvo3-hpvr2nve-cp-req/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for your work on this draft. In light of Spectre and Meltdown, I am > wondering if there needs to be more explicit text in the draft on tenant > isolation. > > Could you expand the pros and cons of the choices listed out in the security > considerations section in the following sentence? Additional context would > be helpful for the reader. > > One design point is whether the hypervisor > should supply the NVE with necessary information (e.g., VM addresses, > VN information, or other parameters) that the NVE uses directly, or > whether the hypervisor should only supply a VN ID and an identifier > for the associated VM (e.g., its MAC address), with the NVE using > that information to obtain the information needed to validate the > hypervisor-provided parameters or obtain related parameters in a > secure manner. > > [yz] I am thinking to add the following after the abovementioned text for > better explanations. > "The former approach can be used in a trusted environment so that the > external NVE can directly use all the information retrieved from the > hypervisor for local configuration. It saves the effort on the external NVE > side from information retrieval and/or validation. The latter approach gives > more reliable information as the external NVE needs to retrieve them from > some management system database. Especially some network related parameters > like VLAN IDs can be passed back to hypervisor to be used as a more > authoritative provisioning. However in certain cases, it is difficult or > inefficient for an external NVE to have access or query on some information > to those management systems. Then the external NVE has to obtain those > information from hypervisor. > > Since the communications happen in multiple ways, I'm wondering how isolation > is considered for each. I see the text on authentication, ACLs and filter > rules and that is all good, but I'm wondering if more is needed (firmer > wording specific to isolation, etc.). From the intro: > > In such cases, there is > no need for a standardized protocol between the hypervisor and NVE, > as the interaction is implemented via software on a single device. > While in the Split-NVE architecture scenarios, as shown in figure 2 > to figure 4, control plane protocol(s) between a hypervisor and its > associated external NVE(s) are required for the hypervisor to > distribute the virtual machines networking states to the NVE(s) for > further handling. The protocol is an NVE-internal protocol and runs > between tNVE and nNVE logical entities. This protocol is mentioned in > the NVO3 problem statement [RFC7364] and appears as the third work > item. > > Sect 4: The authentication requirement could be stronger, is there a reason > it isn't? > Req-11: The protocol MUST allow the External NVE to authenticate the > End Device connected. > > If this is not in software as one option provides, there is no statement on > encrypted sessions, is there a reason why this is not needed? > > [yz] This document tries to address the requirement between hypervisor and > the external NVE, normally single hop only. The traffic isolation between > them is by locally significant tag, usually VLAN. Section 2.1 pp2 states > "Both the hypervisor and external NVE sides must agree on that tag value for > traffic identification, isolation, and forwarding." > [yz] As the protocol is used between server and ToR switch in data center > which is believed a trustworthy environment, encrypted session is a pretty > weak requirement over a single hop here. VM migration is expected to be fast > and encryption session requires key exchanges which takes time and resources. > We do not intend to put it as a requirement. But existing mechanism like > MACsec is applicable if people wants secure channel. Maybe we can briefly > mention applicability of current secure channel mechanism in security > considerations section. > > I also don't see a requirement on logging, should there be one? If not, why > not? Are there security policy management functions that would need to track > the connections between tenant systems and external NVEs to prove isolation > or track the paths? > > I do see this in Sect 3.2: > An external NVE may report the mappings of its underlay IP > address and the associated TSI addresses to NVA and relevant network > nodes may save such information to their mapping tables but not their > forwarding tables. > > Is more needed? Maybe not, but if you could explain or adjust text and > possibly the requirements, I'd appreciate it. > [yz] The key "logging" information is basically the mapping information for > underlay<->overlay address and local tag<->VNI on NVA. The document is trying > to focus on split-NVE rather than NVE-NVA, so some of the interleaved > interaction between NVE and NVA are not specified and some like address > mappings are shown here and there in section 3. I think adding something > like " locally significant tag and VNI mapping to be reported to NVA when > locally significant tag information is provided by hypervisor " to section > 3.1 makes sense as it is key information. > _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
