Split Network Virtualization Edge (Split-NVE) Control-Plane Requirements

Note: This ballot was opened for revision 15 and is now closed.

(Alia Atlas) Yes

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2018-02-21 for -15)
No email
send info
Substantive Comments:

§1.2: It would be helpful to see the TSI labeled in the figures.

§6: Are there requirements for the tenant system to ensure that it is connecting to the correct nNVE?

Editorial Comments and Nits:

§1: Please expand tNVE and nNVE

§6: "... that any hypervisor wishing to use the services of an NVE are properly authorized..."
plural disagreement (s/ are / is

§7: IANA (weakly) recommends that the IANA section be retained even when empty. (It's still the authors' call.)

§9: "merger from the drafts"

Alissa Cooper No Objection

Suresh Krishnan No Objection

Mirja Kühlewind No Objection

(Terry Manderson) No Objection

(Kathleen Moriarty) No Objection

Comment (2018-02-21 for -15)
No email
send info
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

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.

Alvaro Retana No Objection

Adam Roach No Objection