Subject: Re: Guidance needed on well known ports

From: [email-masked] (Noel Chiappa)
Date: Mon, 20 Mar 2006 12:47:46 -0500 (EST)

> From: Keith Moore <[email-masked]>

    > Regarding SRV, it's not acceptable to expect that as a condition of
    > deploying a new application, every user who wishes to run that
    > application be able to write to a DNS zone. Most users do not have DNS
    > zones that they can write to.

Yes. Architecturally speaking, it's somewhat dubious that information which
really only needs to be localized to the host (application<->port binding)
has to be sent to the DNS.

It would be easy to run a tiny little USP "binding" server that took in an
application name (yes, we'd have to register those, but string-space is
infinite), and returned the port.

About the only reason I can see that that would not be desirable would be to
avoid an extra RTT to the do that binding lookup. (DNS/SRV solutions might
avoid this RTT too, but in that case that benefit doesn't outweigh the
costs.) The "obvious" way to do it, which is have the ICP use the strings
directly (as the CHAOS protocols did) is not really feasible now - it would
require a change to TCP.

Another option, now that I think about it, though, is a TCP option which
contained the service name - one well-known port would be the "demux port",
and which actual application you connected to would depend on the value in
the TCP option.

    > Furthermore it's increasingly necessary that applications be able to
    > work in environments that do not use DNS - such as ad hoc networks or
    > networks that become isolated.

Also a good point.

    > Probably the worst problem with destination port numbers is that there
    > aren't enough of them. That's probably something that needs to be
    > addressed in TCP and UDP

No, 65K is probably enough (because, recall that a single port can have
connections to hundreds of thosands of foreign ports) *provided* that we
don't have to assign a well-known port to each application.

It's the concept of well-known ports that's broken, not the provision for 65K
ports.

	Noel

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 20 Mar 2006 12:57:53 -0500

On Mon, 20 Mar 2006 12:47:46 -0500 (EST), [email-masked] (Noel

> and which actual application you connected to would depend on the value in
Like tcpmux, port 1, RFC 1078?

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: Keith Moore <[email-masked]>
Date: Mon, 20 Mar 2006 13:09:01 -0500

> It's the concept of well-known ports that's broken, not the provision for 65K

offhand I don't see why we need two kinds of names for services,
because that creates the need for a way to map from one constant to
another - and that mapping causes failures which seem entirely
unnecessary.

I do see the need to allow applications to talk to non-default service
names (say for testing or other special cases) but that's a
separate issue.

regarding service names, a bit string should be fine, as long as it's
not restricted to some short length.  16 bits is not enough in the long
term.  

I don't have much of a problem with services named using character
strings either, except that these days such discussions inevitably
bring up internationalization issues that I'd rather avoid. 

most of this is probably moot as I doubt we have the luxury of starting
from scratch.  but in terms of where we want to be, I think it makes
more sense to extend the port # space than to insist that everyone use
a separate and less reliable means of mapping between character service
names and port #s.

---

From: Peter Dambier <[email-masked]>
Date: Mon, 20 Mar 2006 21:20:04 +0100

> 		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

How bout the NIS portmapper on port 111 and RFC 1057

-- 
Peter and Karin Dambier
The Public-Root Consortium
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [email-masked]
mail: [email-masked]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 20 Mar 2006 15:54:57 -0500

> How bout the NIS portmapper on port 111 and RFC 1057
Most services do not use RPC.  Virtually all of our TCP client-server
protocols would run unchanged after connection establishment with
TCPMUX.

---

From: Joe Touch <[email-masked]>
Date: Thu, 23 Mar 2006 20:36:05 -0800

> infinite), and returned the port.

Only if it asked a well-known server ON THAT MACHINE. I.e., pick a port,
reserve it for resolution (e.g., like the RPC portmapper works).

But we cannot assume a hosts' DNS is available for that purpose. For
most of us, the DNS entry isn't under our control, nor is it likely to
be for the forseeable future.

> directly (as the CHAOS protocols did) is not really feasible now - it would

That could be done using a late-binding trick like we used for
string-based source routing (www.isi.edu/datarouter); we could have a
TCP option where the service name occurs (as below), and send it at
first to the 'portmapper' port, which would demux it and return it. That
does require a mod to TCP to allow the dest port to be unbound (e.g.,
'0') if the option is present, and enable the return SYN-ACK to update
the TCB on arrival.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 23 Mar 2006 20:37:30 -0800

> Like tcpmux, port 1, RFC 1078?

Exactly, except to use a TCP option rather than putting the port name in
the data stream - where it isn't available until the data is already
being exchanged (and ack'd).

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 23 Mar 2006 20:56:51 -0800

PS...

> '0') if the option is present, and enable the return SYN-ACK to update

Since it seems like this might be useful, I'll pull a draft together on
how to do this without 1078's extra connection, more like the
late-binding we do in datarouter, very shortly...

Joe

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Fri, 24 Mar 2006 08:23:20 -0500

On Thu, 23 Mar 2006 20:56:51 -0800, Joe Touch <[email-masked]> wrote:

> late-binding we do in datarouter, very shortly...

1078 doesn't use an extra connection; it hands off the open connection
to the protocol handler.

Your suggestion of using a TCP option instead is friendlier to
firewalls, though.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 24 Mar 2006 08:33:54 -0600

> late-binding we do in datarouter, very shortly...
This sounds like a neat extension.

Eliot