Re: Re: [virtio-comment] Re: Re: Re: [PATCH v2 09/11] transport-fabrics: add TCP&RDMA binding

[zhenwei pi <pizhenwei@bytedance.com>]

On 6/6/23 21:51, Stefan Hajnoczi wrote:
> On Tue, Jun 06, 2023 at 09:41:09AM +0800, zhenwei pi wrote:
>> On 6/6/23 00:57, Stefan Hajnoczi wrote:
>>> On Fri, Jun 02, 2023 at 05:07:14PM +0800, zhenwei pi wrote:
>>>>
>>>>
>>>> On 6/1/23 05:02, Stefan Hajnoczi wrote:
>>>>> On Thu, May 04, 2023 at 04:19:08PM +0800, zhenwei pi wrote:
>>>>>> Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
>>>>>> ---
>>>>>>     transport-fabrics.tex | 9 +++++++++
>>>>>>     1 file changed, 9 insertions(+)
>>>>>>
>>>>>> diff --git a/transport-fabrics.tex b/transport-fabrics.tex
>>>>>> index f563c3e..c47a744 100644
>>>>>> --- a/transport-fabrics.tex
>>>>>> +++ b/transport-fabrics.tex
>>>>>> @@ -873,3 +873,12 @@ \subsubsection{Status Definition}\label{sec:Virtio Transport Options / Virtio Ov
>>>>>>     #define VIRTIO_OF_EALREADY      114
>>>>>>     #define VIRTIO_OF_EQUIRK        4096
>>>>>>     \end{lstlisting}
>>>>>> +
>>>>>> +\subsection{Transport Binding}\label{sec:Virtio Transport Options / Virtio Over Fabrics / Transport Binding}
>>>>>> +\subsubsection{TCP}\label{sec:Virtio Transport Options / Virtio Over Fabrics / ransport Binding / TCP}
>>>>>> +TCP MUST use \ref{sec:Virtio Transport Options / Virtio Over Fabrics / Transmission Protocol / Commands Definition / Stream Transmission}
>>>>>> +~\nameref{sec:Virtio Transport Options / Virtio Over Fabrics / Transmission Protocol / Commands Definition / Stream Transmission}.
>>>>>> +
>>>>>> +\subsubsection{RDMA}\label{sec:Virtio Transport Options / Virtio Over Fabrics / ransport Binding / RDMA}
>>>>>> +RDMA MUST use \ref{sec:Virtio Transport Options / Virtio Over Fabrics / Transmission Protocol / Commands Definition / Keyed Transmission}
>>>>>> +~\nameref{sec:Virtio Transport Options / Virtio Over Fabrics / Transmission Protocol / Commands Definition / Keyed Transmission}.
>>>>>
>>>>> What about VQN representation, default port numbers, etc? There should
>>>>> be enough information here so implementers can create compatible
>>>>> implementations.
>>>>>
>>>>
>>>> Already replied in '[PATCH v2 02/11] transport-fabrics: introduce Virtio
>>>> Qualified Name'.
>>>>
>>>>> Is there connection encryption support? It's hard to imagine running a
>>>>> plaintext Virtio Over Fabrics TCP connection in a production environment
>>>>> due to security concerns.
>>>>>
>>>>> Stefan
>>>>
>>>> As far as I can see, 1) an ACL mechanism could be used in the engineering
>>>> implementation without any specification.(ex, a target only allows a
>>>> specific IVQN). 2) authentication may be introduced in the future.
>>>>
>>>> Does the virtqueue buffers need encryption support?
>>>
>>> An ACL in the target is still susceptible to attacks on confidentiality
>>> (spying on traffic) and integrity (spoofing, injecting, or corrupting
>>> traffic).
>>>
>>> My view is that nowadays anything that goes over the network needs
>>> Transport Layer Security (TLS) built in or something comparable unless
>>> the use cases are clearly limited to scenarios where this is not
>>> necessary. To me it seems like Virtio over Fabarics could be used in
>>> scenarios where encryption is necessary (e.g. to protect user data being
>>> sent over a network).
>>>
>>> NVMe-over-TCP supports TLS.
>>>
>>> Stefan
>>
>> Generally, LAN is considered to be secure, using TCP makes sense. TLS is
>> needed for WAN.
> 
> This depends on the security policy of the organization. I don't know
> what percentage of organizations trust internal networks, but I'm sure
> there is a significant proportion of organizations nowadays where
> deploying an unsecured network service is not allowed.
> 
> Also, Virtio Over Fabrics (TCP) will work over the internet and some
> users may use it for that.
> 
> I think including optional TLS support from the beginning is necessary.
> 
> Stefan

Agree with the optional TLS support. Let's continue the detail 
discussion in '[PATCH v2 06/11] transport-fabrics: introduce command set'.

-- 
zhenwei pi

This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/