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