4:44 p.m.
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 -=|
4:29 a.m.
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(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
6:09 a.m.
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
7:18 a.m.
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(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
7:31 a.m.
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
7:45 a.m.
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 -=|
7:27 a.m.
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 -=|
7:32 a.m.
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
6367
days inactive
6368
days old
7 comments
3 participants
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
Richard W.M. Jones