Subject: [nvo3] Kathleen Moriarty's No Objection on draft-ietf-nvo3-hpvr2nve-cp-req-15: (with COMMENT)

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 21 Feb 2018 20:07:25 -0800

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.

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?

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.

---

From: Liyizhou <[email-masked]>
Date: Thu, 22 Feb 2018 08:52:48 +0000

Hi Kathleen,

Thanks for your comments. Please see inlines with [yz].

Rgds,
Yizhou

-----Original Message-----
From: Kathleen Moriarty [mailto:[email-masked]] 
Sent: Thursday, February 22, 2018 12:07 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; Matthew Bocci <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Kathleen Moriarty's No Objection on draft-ietf-nvo3-hpvr2nve-cp-req-15: (with COMMENT)

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.)

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.

[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

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?

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.

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 22 Feb 2018 07:46:00 -0500

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 <[email-masked]> wrote:
> 
> Hi Kathleen,
>