[Libvir] Register libvirtd ports with IANA ?
For the libvirtd we currently use two ports 16509 - TCP unencrypted stream 16514 - TLS encrypted stream My first thought is that we should really use consequetive port numbers eg 16510 and 16511. Second, we should register our port numbers with IANA http://www.iana.org/protocols/forms.htm Thoughts ? Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On Sun, Jun 17, 2007 at 10:44:05PM +0100, Daniel P. Berrange wrote:
For the libvirtd we currently use two ports
16509 - TCP unencrypted stream 16514 - TLS encrypted stream
My first thought is that we should really use consequetive port numbers eg 16510 and 16511.
that would be nicer
Second, we should register our port numbers with IANA
http://www.iana.org/protocols/forms.htm
Thoughts ?
it's better to do it than not do it :-) The worse case would be a rejection. I think we need to use that form http://www.iana.org/cgi-bin/usr-port-number.pl I see XenSource already registered 1 port: xsmsvc 6936/tcp XenSource Management Service xsmsvc 6936/udp XenSource Management Service # Roger Klorese <roger&xensource.com> June 2006 and the 2 you suggest are in a currently unassigned area ------------------------- # 15346-15362 Unassigned 3link 15363/tcp 3Link Negotiation 3link 15363/udp 3Link Negotiation # Brant Thomsen <brant_thomsen&3com.com> January 2003 # 15364-15554 Unassigned cisco-snat 15555/tcp Cisco Stateful NAT cisco-snat 15555/udp Cisco Stateful NAT ------------------------- Let's discuss the content of the form submission: Your Name: / Your E-mail: I guess potentially me, Dan or Rich could be the point of contact. I'm not against doing it, I'm not against someone else doing it :-) 3 "What message formats are used?" If I understand correctly in the first case we could describe succintly the remote_message_header from remote_protocol.h there, at least for the encrypted version. 4 "What message types are used?" that would correspond more or less to remote_message_direction 5 "What message op codes are used?" remote_procedure enum would fit, not sure they want a complete dump though. 6 "What message sequences are used?" Request/reply pairs with optional asynchronous messages. 7 "What functions are performed by this protocol?" Provide a remote access mechanism for a virtualization API. "no broadcast or multicast" 8 " Please give us a technical description of your proposed use of the user port number. (At least 2 paragraphs)" Hum .... let's try : --------------------------------- When the virtualization layer is started on servers, a daemon is created to serve local and remote requests allowing control of the virtualization engine. This includes monitoring of the hypervisor and running domains, and the possibility to create, control and destroy the set of domains running. The port is opened by the daemon waiting for requests. User of the libvirt API (see http://libvirt.org/) on the controling host(s) will open a connection to the daemon for the time the application will need to monitor the virtualization. [After successful TLS authentication ] the daemon will process requests corresponding to entry points in the libvirt API. Requests are read from the socket and processed locally, and the result is returned as a reply message. There is also a need to send asynchronous messages to provide feedback on specific condition which may arise in the host or to local virtualized domains. The connection is usually closed when the application stops monitoring the remote node. --------------------------------- 9 "What is the proposed name of the user port number? " Virtualization Management Service or Libvirt Management Service I'm not sure if we should put the library name there or the kind of service. 10 " What SHORT name (14 CHARACTER MAXIMUM) do you want associated with this port number?" libvirt Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Daniel P. Berrange wrote:
For the libvirtd we currently use two ports
16509 - TCP unencrypted stream 16514 - TLS encrypted stream
My first thought is that we should really use consequetive port numbers eg 16510 and 16511.
A few comments ... We don't need to use two ports if we either use a "STARTTLS"-style upgrading of unencrypted to encrypted connections (which is the recommended way to do things instead of using two ports), or more simply we just ditch unencrypted connections. They're disabled by default anyway and not in any way required unless we want libvirt to build without GnuTLS. The port number (16514) is not allocated by IANA, which is good. IANA registration is a good thing because it makes it less likely that libvirtd will fail to start because some other service is using that port. No one got my ZX81 joke, obviously ... Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
On Mon, Jun 18, 2007 at 12:09:33PM +0100, Richard W.M. Jones wrote:
Daniel P. Berrange wrote:
For the libvirtd we currently use two ports
16509 - TCP unencrypted stream 16514 - TLS encrypted stream
My first thought is that we should really use consequetive port numbers eg 16510 and 16511.
A few comments ...
We don't need to use two ports if we either use a "STARTTLS"-style upgrading of unencrypted to encrypted connections (which is the recommended way to do things instead of using two ports), or more simply we just ditch unencrypted connections. They're disabled by default anyway and not in any way required unless we want libvirt to build without GnuTLS.
Well if we can implement the detection automatically, I'm all for reducing to a single port ! I still want to be able to build without the dependancy and optionally allow unencrypted connections.
No one got my ZX81 joke, obviously ...
Ahum, I certainly didn't, my childhood memory includes an UNIVAC but no ZX81! Heh Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Daniel Veillard wrote:
On Mon, Jun 18, 2007 at 12:09:33PM +0100, Richard W.M. Jones wrote:
Daniel P. Berrange wrote:
For the libvirtd we currently use two ports
16509 - TCP unencrypted stream 16514 - TLS encrypted stream
My first thought is that we should really use consequetive port numbers eg 16510 and 16511. A few comments ...
We don't need to use two ports if we either use a "STARTTLS"-style upgrading of unencrypted to encrypted connections (which is the recommended way to do things instead of using two ports), or more simply we just ditch unencrypted connections. They're disabled by default anyway and not in any way required unless we want libvirt to build without GnuTLS.
Well if we can implement the detection automatically, I'm all for reducing to a single port !
I don't know if we can detect TLS automatically. I guess it may be possible to detect the handshake message. Anyhow, the standard way[1] to do this is to establish the connection in unencrypted mode, then (as part of the protocol) upgrade the connection to an encrypted one. The STARTTLS RFC is quite enlightening: http://www.ietf.org/rfc/rfc2487.txt but their concerns also revolve around backwards compatibility -- it must always be possible to interoperate with non-TLS-supporting MTAs -- and that's not a problem that we have. Upgrading connections in this way is subject to an easy man-in-the-middle attack, unless the client and server are able to specify in some way that they only want to talk over a secured connection. I think we should wait on Dan's stuff before changing this.
I still want to be able to build without the dependancy and optionally allow unencrypted connections.
Rich. [1] From http://www.ietf.org/rfc/rfc2817.txt: At the Washington DC IETF meeting in December 1997, the Applications Area Directors and the IESG reaffirmed that the practice of issuing parallel "secure" port numbers should be deprecated. The HTTP/1.1 Upgrade mechanism can apply Transport Layer Security [6] to an open HTTP connection. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
On Mon, Jun 18, 2007 at 01:31:15PM +0100, Richard W.M. Jones wrote:
Daniel Veillard wrote:
On Mon, Jun 18, 2007 at 12:09:33PM +0100, Richard W.M. Jones wrote:
Daniel P. Berrange wrote:
For the libvirtd we currently use two ports
16509 - TCP unencrypted stream 16514 - TLS encrypted stream
My first thought is that we should really use consequetive port numbers eg 16510 and 16511. A few comments ...
We don't need to use two ports if we either use a "STARTTLS"-style upgrading of unencrypted to encrypted connections (which is the recommended way to do things instead of using two ports), or more simply we just ditch unencrypted connections. They're disabled by default anyway and not in any way required unless we want libvirt to build without GnuTLS.
Well if we can implement the detection automatically, I'm all for reducing to a single port !
I don't know if we can detect TLS automatically. I guess it may be possible to detect the handshake message. Anyhow, the standard way[1] to do this is to establish the connection in unencrypted mode, then (as part of the protocol) upgrade the connection to an encrypted one.
The STARTTLS RFC is quite enlightening: http://www.ietf.org/rfc/rfc2487.txt but their concerns also revolve around backwards compatibility -- it must always be possible to interoperate with non-TLS-supporting MTAs -- and that's not a problem that we have.
Upgrading connections in this way is subject to an easy man-in-the-middle attack, unless the client and server are able to specify in some way that they only want to talk over a secured connection.
Basically we'd need one extra packet exchange between client & server before beginning the main protocol. - Clients sends a single byte, which is a bitfield indicating supported data encoding streams 1 - Plain, no encoding 2 - TLS encrypted So if a client was happy with either it would send '3', or if it only wanted a secure connection it would send '2'. - Server looks at bitfield sent by client & picks its preferred encoding. It returns a single byte indicating the encoding chosen 0 - Rejected all client requested encodings 1 - Plain, no encoding 2 - TLS encrypted This still leaves us 6 bits to spare for future. Though if we're paranoid we could send a u64 back & forth - the overhead is going to the be roundtrip, not the size of data. That would give us a nice 62 bits spare to play with in the future if we hit some really horrible compatability problem we needed to negotiate at startup. Dan -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On Mon, Jun 18, 2007 at 12:09:33PM +0100, Richard W.M. Jones wrote:
Daniel P. Berrange wrote:
For the libvirtd we currently use two ports
16509 - TCP unencrypted stream 16514 - TLS encrypted stream
My first thought is that we should really use consequetive port numbers eg 16510 and 16511.
A few comments ...
We don't need to use two ports if we either use a "STARTTLS"-style upgrading of unencrypted to encrypted connections (which is the recommended way to do things instead of using two ports), or more simply we just ditch unencrypted connections. They're disabled by default anyway and not in any way required unless we want libvirt to build without GnuTLS.
The TCP stuff would be useful if you made it listen on 127.0.0.1 and were using SSH to connect to libvirt remotely. So since the client sides has SSH tunnellin support we probably ought to keep the plain TCP server, since you don't want to be tunnelling TLS over SSH :-)
No one got my ZX81 joke, obviously ...
What's a ZX81 ;-P Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
Daniel P. Berrange wrote:
On Mon, Jun 18, 2007 at 12:09:33PM +0100, Richard W.M. Jones wrote:
Daniel P. Berrange wrote:
For the libvirtd we currently use two ports
16509 - TCP unencrypted stream 16514 - TLS encrypted stream
My first thought is that we should really use consequetive port numbers eg 16510 and 16511. A few comments ...
We don't need to use two ports if we either use a "STARTTLS"-style upgrading of unencrypted to encrypted connections (which is the recommended way to do things instead of using two ports), or more simply we just ditch unencrypted connections. They're disabled by default anyway and not in any way required unless we want libvirt to build without GnuTLS.
The TCP stuff would be useful if you made it listen on 127.0.0.1 and were using SSH to connect to libvirt remotely. So since the client sides has SSH tunnellin support we probably ought to keep the plain TCP server, since you don't want to be tunnelling TLS over SSH :-)
Why's that any more useful than the current ssh method, which uses Unix domain sockets? Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
Richard W.M. Jones