overlay cloud service provider vs cloud service provider

[mglt]

1. Section 2: The second paragraph assumes overlay cloud service provider may be different from Cloud service provider. While this may be a possibility, most common use cases should be outlined in this paragraph and in the list of scenarios in the last paragraph of this section. For example data center operator or cloud service provider hosts tenant systems and provides virtual network as a service. The underlay infrastructure including servers and data center network are managed by the same service provider. The last paragraph of this section should identify which provider manages the NVE and orchestrates tenant systems.

[mglt]

The second paragraph of section 2 is the text below: """ The underlay infrastructure on which the multi-tenancy overlay networks are hosted, can be owned and provided by an underlay provider who may be different from the overlay cloud provider. """

The last paragraph of this section is the text below: """ Given the different relations between Tenant, Geneve Overlay Provider and Infrastructure Provider, this document aims providing requirements to ensure: 1. The Geneve Overlay Provider delivers tenant payload traffic (Geneve inner payload) and ensuring privacy and integrity. 2. The Geneve Overlay Provider provides the necessary means to prevent injection or redirection of the Tenant traffic from a rogue node in the Geneve overlay network or a rogue node from the infrastructure. 3. The Geneve Overlay Provider can rely on the Geneve overlay in term of robustness and reliability of the signaling associated to the Geneve packets (Geneve tunnel header, Geneve header and Geneve options) in order to appropriately manage its overlay. """

If I understand correctly, the comment says that the most common use case- a Cloud Provider providing the virtual network as a service - should be listed. I am inclined to think that use cases popularity is out of the scope of a security analysis.

This document elaborates a model to perform a security analysis. The model defines roles and relations between them as specified in the Geneve architecture document. That a specific combination is popular/common or not should not impact the security analysis. Typically, while the most common use case of today is likely to evolve over time, the security analysis must not. As a result, considering use cases here seems to me out of scope of the document.

As a side note, basing the security analysis on specific use cases is likely to create security vulnerabilities for deployment that do not exactly match the considered most common use case. As a result, this will limit drastically the usage of the protocol to a specific use case, which is probably not what we are looking for.

Do we agree that use cases and security analysis are orthogonal, or do you believe we should still add some considerations of the use cases ?