[Libvir] Register libvirtd ports with IANA ?

[Richard W.M. Jones]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20070618/950b15f3/attachment-0001.bin>