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