Subject: Guidance needed on well known ports

From: Eliot Lear <[email-masked]>
Date: Sat, 18 Mar 2006 09:38:05 -0800

Hello all,

In trudging along with the NETCONF specs we hit a bump when the IANA
asked what type of ports we would like, whether they should be well
known ports or not.  The working group has churned for a while on this
and while almost everyone agrees it's a minor thing, it seems we need
some guidance on when well known ports should be used.

On the one hand, NETCONF cannot at this time claim to be widely
implemented and so it's not all that well known.  By this argument it
should be assigned a port > 1024.  On the other hand, few protocols out
of the box are well known, and it would seem foolish to allocate new
ports when a protocol becomes well known.

The argument has been made that ports < 1024 are privileged and hence
these ports should be reserved for sensitive system services, and that
configuration services fit within that definition.  On the other hand,
this seems archaic and more in the realm of OS implementations as to
what process can bind to a port.

A third argument could be made that the decision should be based on
whether the community believes the protocol is "important" enough to
assign a well known port.  This vague notion may be appropriate but it
is something that is difficult for a spec author or even a working group
to decide.

This therefore leads to two questions for the community:

   1. Are well known ports archaic?  If so, can we request that the IANA
      do away with the distinction?
   2. If they are not archaic, under what circumstances should they be
      allocated?

My own opinion:

They are archaic and the distinction should be dropped.  Many operating
systems do not make the distinction (particularly special purpose ones)
and those that do would be better off providing a finer grain control
over what processes can bind to ports.

If you disagree then I claim that the decision to allocate a well known
port should be based on the need of an operating system to protect that
service against user interference a/o denial of service, since the only
benefit of a well known port is that non-privileged processes may not be
able to bind to ports below 1024.  Therefore it follows that device
management services deserve well known ports, and NETCONF fits the bill.

Comments?

Eliot

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 18 Mar 2006 15:58:48 -0500

I would not that starting dynamic ports above 1024 or even above 4096 
is not sufficient.  There are already services with assigned ports 
higher than that.  And it keeps growing.  The IANA list of well-known 
ports is quite long.

If we could go back and start over, something like dynamic DNS and 
SRV records would get us out of the mess.  But that is not a viable choice.

Yes, whenever possible one starts services before applications which 
grab dynamic port numbers.  Unfortunately, that sometimes does not work.

All that aside, the IANA has a distinction (based on history) between 
ports below 1024 and those above.  And whne asking for a port number 
assignment, one specifies which range one wants.  I had least can not 
find a coherent strategy for what should be on one side or the other 
of that boundary.

Yours,
Joel

At 03:41 PM 3/18/2006, Christian Huitema wrote:
> > A more interesting question is this: what are the odds that a user
> > process will accidentally grab the port number before the system
> > process gets to it?  The notion of a "privileged" port number is
> > certainly preposterous; that said, putting services in a range that
> > ordinary applications tend not to use has its merits.
>
>There are two issues there, accidental collision between a dynamic port
>and a service port, and "voluntary" collision between applications
>trying to open the same port.
>
>The practical solution to the first problem are to start services and
>grab ports as part of the boot sequence, i.e. before user processes
>start, and start dynamic allocations at some high number (e.g. larger
>than 1024 or larger than 4096 or some admin defined value depending on
>system version and configuration). If there is a reserved range, then it
>is easy to start dynamic allocation outside the range.
>
>Starting services quickly also helps with the "voluntary collisions"
>between system services and applications, but is not foolproof. In any
>case, it does not help with collisions between applications, e.g. two
>applications trying to use the same port. What does help there is an
>easily accessible registration system, so application developers can
>easily "do the right thing", i.e. reserve a port and avoid collisions.
>Note the emphasis on "easily accessible": if there are too many hoops to
>jump through, the developers will likely just pick a number at random.
>
>-- Christian Huitema
>
>
>_______________________________________________
>Ietf mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ietf

---

From: Peter Dambier <[email-masked]>
Date: Sun, 19 Mar 2006 01:56:10 +0100

Steven M. Bellovin wrote:
> On Sat, 18 Mar 2006 12:41:25 -0800, "Christian Huitema"
> <[email-masked]> wrote:
> 
>>If there is a reserved range, then it
> Yes -- this is my point.  I don't care about Unix-style privileged
> ports (and have never liked them anyway), but putting most services
> outside the well-known dynamic range is a good idea.

Yes, I agree, http should never have been assigned port 80. Randomly
looking for ports would make a lot more fun.

Maybe it is archaic, that all operating systems treat ports below
1024 special. But still they do. A normal user cannot gain access
to these ports.

Windows?

Is just a randomly changeing mess of dynamic link libraries that is
permanently modified by applications, viruses and the so called
operating system proper. The api is kept a trade secret.

VM, MVS, BS2000, VMS, all flavours of Unix including Minix, MAC OS-X,
BSD and Linux treat ports below 1024 special.

Special ports are required by servers running on real operating
systems. A windows client might be the user of such a port but
not the server. Or do you want to install a "trunk monkey" on
every host who takes care of an emerging error window and gives
the mouse a push?

How about a portmapper. It works with NIS and NFS. Yes the
port mapper needs a reserved port too, but that is already
allocated. Portmapper is a security hole but so is a randomly
changeing mess of DLLs.

>>jump through, the developers will likely just pick a number at random.

The portmapper is such a registration system.

I guess the port 42 nameserver was very early allocated and it still
works nicely for me but that could not prevent a collision with the
peculiar use of port 42 by windows.

> 
> Right, though it's a delicate dancce.

I agree, and please keep http on port 80 :)

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

Cheers
Peter nd Karin
-- 
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: Sat, 18 Mar 2006 15:54:53 -0500

---

From: "Christian Huitema" <[email-masked]>
Date: Sat, 18 Mar 2006 10:44:13 -0800

>       do away with the distinction?

I don't know whether I would use the word "archaic", but the distinction
between < 1024 and >= 1024 is certainly Unix-specific. In the Windows
operating systems, the port range 1-1023 is not special. Some Windows OS
services use low port numbers, but not all. UPNP, for example, uses
ports 1900 and 2500; the RPC applications use dynamic port numbers.

>    2. If they are not archaic, under what circumstances should they be

I have no problem with the current system.

-- Christian Huitema

---

From: "Christian Huitema" <[email-masked]>
Date: Sat, 18 Mar 2006 12:41:25 -0800

-- Christian Huitema

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Sat, 18 Mar 2006 14:21:17 -0500

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 19 Mar 2006 05:24:32 +0100

>    2. If they are not archaic, under what circumstances should they be
My opinion:

they are archaic and should be dropped. A number is a number, and the 
Unix "protection" policy has led directly to security exploits because 
processes were running as root because they "had to" in order to open a 
low port number.

That said - we need advice on, and probably a distinction between, 
"dynamic" ports and "ports that you get by asking for them".
OSes may also want to attach specific ACLs to specific ports on specific 
systems - but that's outside of what the IETF has traditionally set 
standards for.

My short term advice to netconf:

Flip a coin. Heads, go for a system port. Tails, go for a well known 
port. It's more important to get past the issue than what you decide.

My two cents.

                  Harald

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 19 Mar 2006 23:23:45 +0100

Regardless of what the community consensus is on:

>    1. Are well known ports archaic?

I want to comment that on this:

>  If so, can we request that the IANA

The IETF decides, and the IANA will then be responsible for implementing the decision.

    Brian

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 20 Mar 2006 11:48:56 +0100

We seem to agree that the choice of port range is not the most important item for Netconf. 
So anything is OK but decide fast. Maybe the chairman can just decide this or have a vote 
till today midnight.
Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]