[Spice-devel] An overview of Network redirection in Spice

[Yaniv Kaul]

On 2010-03-02 16:29, Yonit Halperin wrote:
> Hi,
> I’ve previously worked on the network redirection feature, which part of
> it is already in the upstream. Here, I present an overview of this feature
> and its status.
>
> Motivation
> ----------
> In many scenarios, the network that the Spice client resides in is not
> accessible from the virtual machine. Thus, the user cannot access
> resources that are located in the client's network (e.g., network
> printers). The suggested solution provides an almost transparent access to
> this network.
>    

- Is there really such a requirement? Is there such a real-life 
use-case? From my experience, if the printer is on the network, it can 
be reached from wherever is needed - or is specifically redirected.
- What else besides printing is a good candidate for network 
redirection? I doubt FTP (as the example below) is one of them.
- Aren't you bypassing all network access controls en-route (firewalls, 
ACLs, content-filtering, etc.) ? You are also in the way of WAN 
acceleration devices, which may have helped with the traffic, as well as 
QOS.

> Solution overview
> -----------------
> 1.	An additional virtual network card (nic) is installed on the VM.
> This network card is dedicated for communication with the client-side
> network
> 2.	The nic's subnet is unique (henceforth, the virtual subnet).
>    

What about IPv6?
Why go above layer 2?

> 3.	Resources in the client-side that need to be accessed via the VM
> receive virtual ip addresses in the range of the virtual subnet. The user
> accesses these resources using the virtual ips. Therefore, all the packets
> that are designated to these resources pass through the special nic.
> 4.	All the network packets that pass through the special nic are
> delivered to the Spice Server, via QEMU. Eventually, the actual connection
> and data transfer to/from the physical resource are performed by the Spice
> Client.
> The server a) Performs the network stack analysis of the packets (e.g.,
> handles the TCP protocol); b)  Sends to the client connection-control
> instructions, e.g., open/close connection to a specific resource; c)
> Tunnels to the client the buffers that need to be delivered to a specific
> resource.
> 5.	After a connection to a resource was established, it is
> bidirectional, i.e., the client can tunnel to the server data that was
> originated from the resource and that is designated to the VM. The client
> can also send to the server control messages about the connection (e.g.,
> the connection was closed). The server translates the information to
> network packets and pushes them to the VM through the special nic.
>
> Design details
> --------------
> 1.	Adding a nic: a special network device we added to Qemu, that
> pushes all the packets to spice and can receive packets from spice.
> 2.	Network stack analysis:  we use a modified version of Slirp.
> Slirp was created by Danny Gasparovski. It emulates a PPP or SLIP
> connection over a normal terminal. Qemu use its code mainly for their
> “user” network (the –net user option). The Slirp code in Qemu transfers
> the application layer of the packets to its destination by using BSD
> sockets. However, we need to pass the application layer to/from the Spice
> server. We took the Slirp code from Qemu,
> and changed it to use a general interface for network connections that can
> be set by the user of slirp. We fill it with callbacks to the
> corresponding routines in the server.
> Our intention was to ship Slirp as a library that hopefully will be useful
> for other projects, and that Qemu will be able to use as well.
>    

Take from OpenVPN (or VPNc?) their virtual NIC. Makes more sense to me 
and works.
And the driver is already signed, works on all Windows OSes, etc.


> 3.	Spice: added a designated channel for network redirection. It is
> called “tunnel channel”. Control data and “redirected” data is passed to
> and from the client. The client pushes the redirected data to the
> corresponding network resources and also can receive data from them and
> sends it back to the server (and from there it is sent to the VM).
> 4.	Generating virtual ips: In order to keep the virtual IPs
> consistent with the resources they represent (in a specific network), we
> generate them by hashing identifiers that are unique to the resource and
> to the network it is located in. Thus, in different executions of Spice
> client on the same network, each client-side resource will obtain the same
> virtual IP it obtained in the previous executions. In this manner, we
> preserve the validity of configurations in the VM that employ the virtual
> IPs.
> 5.	Printer discovery: We implemented printer discovery via SNMP and
> DNS-SD.
> Snmp++ library was used for SNMP. For DNS-SD we used Apple Bonjour API,
> while employing avahi-daemon in Linux and Apple Bonjour in Windows.
>    

Nobody but Apple uses Bonjour. How about UPNP and SSDP? SLP On Linux 
(donno if anyone's using it).

> Solution Advantages
> -------------------
> -	Transparent user experience for network services (mainly
> printers). The user just need to know the virtual ip of the printer. We
> can use Gui for that and configuration file.
> -	General solution for network resources (e.g., ftp serves). Not
> only printers.
> -	It can be generalized to local resources as well.
> -	In the tunnel channel there is an option to process the
> application layer - it can function as a firewall.
> -	Other solutions use a special guest-driver and/or a
> guest-application. As far as I know most of them also depends on the
> printer drivers installed on the client machine.
> This solution is cross-platform (client and guest wise) and
> client-independent.
>
> Disadvantages
> -------------
> - Bandwidth: The rendered job (which can be much larger than the original
> file) is sent from the host to the client. This is problematic on WAN.
> (Other solutions send the file as it is to the client, and as mentioned
> before, depend on the drivers on the client machine).
> The tunnel channel traffic should be compressed in order to minimize this
> issue.
> - Installation of drivers on the guest: only by administrator user.
> - Some protocols (e.g., IPP) include the destination and/or src in the
> data. This is problematic when using a virtual ip. In order to fully
> support it we need to process the data itself and serve as proxy. If the
> protocol is also encrypted (an option in IPP), it is even more
> complicated.
>    

That's not going to work. This exactly why VPN clients resorted to 
virtual interfaces on the L2 layer, and redirect from there. The IP is 
the IP they get normally from the DHCP.
There are many protocols that will break - SMB, SIP, for example.
Y.

> Status
> ------
> - Qemu side was implemented but is not yet in upstream, so the whole
> feature is still inactive.
> - Slirp and Spice: TCP support is in upstream (including live migration).
> Bug fixes, Udp support, stable virtual ip generation, printer discovery
> and more – were implemented but haven’t been taken to upstream yet.
> - Slirp – I made some cosmetic changes to the slirp code, fixed some bugs,
> minimized it to work only for network redirection, and modified it to work
> with general interface for sockets. But there is still a lot of work that
> needs to be done in order to make it a real library (e.g., currently there
> is only one instance of it) that not only Spice will want to use. It
> probably should be aligned with upstream Qemu Slirp.
> - Printer-Discovery – (1) need Gui to display printers and their virtual
> ips.
> (2) Apple Bonjour for windows – at the first phase we can require that
> apple bonjour will be installed on the client computer (it is free, and if
> it is not installed only the DNS-SD discovery won't work). Legally, we
> cannot ship Apple binaries with spice. However, at a second phase, we can
> compile them by ourselves and ship them.
> - Printing protocol: After all the changes I made will be applied, raw tcp
> printing (also know as HP JetDirect) is fully supported. IPP also worked
> for me, also through cups (but without any special security
> configuration). Probably there are other protocols that are (or can be
> easily) supported.
>
> Optional features
> -----------------
> - Resolving DNS queries in slirp – the user will be able to use the
> client-side printer names in the virtual network, as they will be resolved
> as virtual ips.
> - Optional general compression layer for all spice channels.
>
>
> Any questions and ideas are welcomed,
> Yonit.
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>