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

[Stefan Hajnoczi <stefanha@redhat.com>]

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

Attachment: signature.asc
Description: PGP signature