[Spice-devel] are there any new spice protocol document?

[Romanovsky Vladislav]

Hi Marc-André,

I read the blueprint and the conversation with Daniel.
To be honest, I'm not that big HTTP fan, so probably I'm missing something.

If I were to write a userspace proxy that supports HTTP Connect, I would just create a
new request handler to handle the CONNECT, get the source host:port and the destination host:port and
connect their sockets, which will create additional connections for all the channels.
(I have that version written as well in the repo.) But that's just me..

However, this is still a userspace proxy. For every connection we will have 4 threads/process(websockets),
that would loop through select() all the time.. 

For Openstack I think it will be painful, considering the attempts to handle thousands of VMs.

Transparent proxy would just forward the packets to the relevant hosts, without copying it between sockets in userspace,
creating a bottleneck on the proxy server and in fact slowing down Spice.
IIRC, Openstack Neurton is doing something similar, regarding forwarding.

In order to address the security issues, we can password protect the spice connection and use ticketing, like Ovirt project does..

However, that's just my POV. 

Which security aspects are concerning you? 
Also, why do you think this approach is limited?

Thanks,
Vladik

----- Original Message -----
> From: "Marc-André Lureau" <mlureau at redhat.com>
> To: "Romanovsky Vladislav" <vromanso at redhat.com>
> Cc: "Dennis Chen" <atticcat at gmail.com>, spice-devel at lists.freedesktop.org, "Christophe Fergeau"
> <cfergeau at redhat.com>, "Artom Lifshitz" <alifshit at redhat.com>
> Sent: Thursday, 23 April, 2015 9:14:21 AM
> Subject: Re: [Spice-devel] are there any new spice protocol document?
> 
> Hi
> 
> ----- Original Message -----
> > A while ago I've started to work on a similar proxy for Spice as part of
> > the
> > Openstack Nova project. However, It should fine to use it without
> > openstack.
> > 
> > So far, there are two working versions, one for userspace and another is a
> > transparent proxy.
> > However, we are now focusing on the transparent one, as the userspace one
> > was
> > slow..
> > 
> > The idea is to setup forwarding rules (iptables) between the client and the
> > spice
> > port on a proxy host. When the client will request a spice console, a new
> > port will be opened
> > on the proxy host, for which forwarding rules will be setup to the
> > destination.
> > The proxy will respond with a port number to which the native client should
> > connect to.
> > It will also monitor the rules and will remove those which are no longer
> > connected.
> > 
> > At the moment we have a working code, but it's far from being in a good
> > shape. (As it was a side project for us so far)
> > There are 2 people involved and each has some part of the code locally.
> > 
> > In the coming days we should be able to consolidate everything in a repo
> > below, however, as far this served
> > us just for hacking.
> > https://github.com/vladikr/spicetcpproxy
> > 
> > We are now in a process of writing a proper blueprint for Nova. Thoughts
> > are
> > more than welcome :)
> 
> How does it compare to:
> https://blueprints.launchpad.net/nova/+spec/spice-http-proxy
> 
> To me it sounds simpler, less limited and more secure to have a single proxy
> port than having to fiddle with forwarding rules.
> 
> cheers
>