Moving Forward with Regularizing Port Numbers

At 2:41 AM -0800 2/6/97, pfh@uk.ibm.com wrote:
>  In summary, my vote is .. propose the new ones that people are already
>using, do not propose ftps until there is at least a commitment from
>some IETF working group to define what it really means  (The ftp one that
>Eric, Tim Hudson and myself are writing is available for adoption !!),
>do not add new ports 'just in case' as this may not be the long-term
>preferred route.

The problem is that people are already using that port number in ftps
implementations, and there is a commitment by multiple people on imap4.

In addition, no single TLS "single-port" proposal that I've seen so far
(including the much appreciated murray internet draft) addresses the issue
of how current firewalls secure ports. The 443 for https has been
acknowledged as a port for http secured with SSL, and if someone inside a
firewall makes a connection out through 443 it is usually allowed (though
it might have to request as per ssl-tunnelling). See the SSL-Talk FAQ
section on "using proxies, gateways and firewalls with ssl" at
<http://www.consensus.com/security/ssl-talk-sec03.html> for some some
discussion on this.

In summary, my position is that there are a number of ports that are
already assigned that need cleanup, and there are at least 2 additional
ones (ftp and imap4) that have multiple people wanting to ship
interoperable products *NOW*. I've also had enough people speak in the last
week about telnet that I'll probably add that to the list. As regards to
irc, rsh, etc. I've had people say that they are doing them, but as I've
only heard of one implementation of each, thus I'm not going to request
those ports.

I agree that this is not a long term solution, and I do not desire to
willy-nilly double the port numbers of every protocol. But there is
precedent of assignment of <1024 port numbers to proprietary applications,
and as there is enough immediate need so that people can have working
interoperable applications in the short term, I think we should go for it.

Thus, unless there are objections by the WG chair or Area Director, I still
plan on submitting the change requests and the 2 (or 3 if I add telnet)
additional requests to the IANA. I will add the information to the request
that one of the reasons driving these requests is issues of current
firewalls, and that this is not a long term solution. If granted, these
ports will be documented in the appendix of the TLS 1.0 draft.

I am willing to commit to a requirements document for TLS 1.1 to address
this issue in the long term. As the post-TLS 1.0 process needs to be more
formal with requirements drafts first, this is one of a couple requirements
documents that we need to do.

Meanwhile, I don't want to hold back implementors with a real need now to
interoperate with SSL 3.0 or TLS 1.0.

------------------------------------------------------------------------
..Christopher Allen                  Consensus Development Corporation..
..<ChristopherA@consensus.com>                 1563 Solano Avenue #355..
..                                             Berkeley, CA 94707-2116..
..Home of "SSL Plus:                      o510/559-1500  f510/559-1505..
..  SSL 3.0 Integration Suite(tm)" <http://www.consensus.com/SSLPlus/>..

Received on Thursday, 6 February 1997 06:36:38 UTC