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

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

---

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: "Randy Presuhn" <[email-masked]>
Date: Sat, 18 Mar 2006 11:05:38 -0800

Hi -

> From: "Christian Huitema" <[email-masked]>
> To: "Eliot Lear" <[email-masked]>; "IETF Discussion" <[email-masked]>
> Cc: "IANA" <[email-masked]>; "Lisa Dusseault" <[email-masked]>; "netconf" <[email-masked]>
> Sent: Saturday, March 18, 2006 10:44 AM
> Subject: RE: Guidance needed on well known ports
...
> I have no problem with the current system.
...

So, under "the current system" (in netconf we're trying to figure out just what
that is) should this protocol be assigned a port number above or below 1024?

Randy

---

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

> ports 1900 and 2500; the RPC applications use dynamic port numbers.

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.

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

---

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

> 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

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Sat, 18 Mar 2006 15:54:53 -0500

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.
> jump through, the developers will likely just pick a number at random.
Right, though it's a delicate dancce.

---

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

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Sat, 18 Mar 2006 23:55:47 +0100

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

new protocols can not rely on the security the priveleged ports provide,
but there are still many such protocols in use (e.g. LPD, port 515), and
so the distinction is useful for administrators configuring userspace'
access to ports on workstations.

> over what processes can bind to ports.

in 2006, if there are DOS or other problems with a protocol which can be
"solved" by using priveleged ports, it shouldn't be published.  so it
should be a "don't care" which block is used for allocation these days.
-- 
Kjetil T.

---

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

> 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: 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: Ned Freed <[email-masked]>
Date: Sun, 19 Mar 2006 12:42:17 -0800 (PST)

> access to ports on workstations.

The problem is this cuts both way. The privileged port concept has some
marginal utility on multiuser systems where you don't Joe-random-user to grab
some port for a well known service. OTOH, this forces servers running on those
ports to have privileges (usually in the form of running as root) for some
period of time. The need to operate with privileges complicates server design,
may impose difficult constraints on activities like configuration reloads, and
may lead to remote vulnerabilities. So, for a production server with no local
users, the privileged port restriction can do much more harm than good. And
finally, we have plenty of protocols that make just as much sense on multiuser
systems as they do on a production server with no local users. So it is
impossible to get this right.

The solution is to abandon the coarse grained root-access-to-low-ports security
model entirely in favor of some form of finer grained access control.
In the meantime, I'm with Harald: Flip a coin and be done with it.

				Ned

---

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: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 20 Mar 2006 12:09:23 +0100

On Sun, Mar 19, 2006 at 12:42:17PM -0800,
 Ned Freed <[email-masked]> wrote 
 a message of 35 lines which said:

> The privileged port concept has some marginal utility on multiuser
> systems where you don't Joe-random-user to grab some port for a well
> known service.

"had", not "has". The concept was invented at a time where multi-users
machines were rare and expensive monsters. So, a request coming from
source port 513 probably was "serious". Today, any highschool student
is root on his PC and therefore this protection is almost useless.

---

From: Andy Bierman <[email-masked]>
Date: Mon, 20 Mar 2006 05:57:17 -0800

> is root on his PC and therefore this protection is almost useless.

But does that student have access to the root account on servers which
are part of the networking infrastructure?   Who cares if Joe User
blows up his own config. on a PC that nobody else depends on but Joe?

I find the argument flawed -- that because Joe User can be root on his 
own PC,
the concept of privileged access to shared system-critical infrastructure is
somehow obsolete.

Andy

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Mon, 20 Mar 2006 16:16:54 +0100

On Mon, 2006-03-20 at 12:09 +0100, Stephane Bortzmeyer wrote:
>  Ned Freed <[email-masked]> wrote:

you shouldn't allow unrestricted access to the network from unmanaged
hosts, that's a recipe for disaster.  consider rogue DHCP servers, for
instance.  we still use host based authentication for port 514 (rsh) on
strictly managed networks as a supplement to SSH.  this requires
physical security for network equipment or exposed hosts (not users)
doing 802.1x authentication.  the protection is not useless in that
environment.
-- 
Kjetil T.

---

From: Ned Freed <[email-masked]>
Date: Mon, 20 Mar 2006 07:37:55 -0800 (PST)

> blows up his own config. on a PC that nobody else depends on but Joe?

But if nobody has local access to these servers, why is it is necessary or
useful for servers to run with root access in order to bind to these ports?

This is why I referred to the utility of this feature as marginal. Its realm
of utility is being squeezed on one side by the trend to run critical network
services on tightly locked down systems rather than on multiuser machines, and
on the other by users who want to run their own stuff doing so on their own
machines.

I simply don't have enough insight into global usage patterns to agree totally
with Staphane's asssrtion that this now has no utility at all. But I think the
trends are pretty clear.

> I find the argument flawed -- that because Joe User can be root on his own PC,

I don't think anyone is claiming that such access needed to be protected. The
issue is rather that the specific mechanism of requiring root can have an
amplifying effect on holes in applications, changing them from a threat to the
application to a way to attack the entire server the application runs on.

				Ned

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 20 Mar 2006 10:08:21 -0600

> useful for servers to run with root access in order to bind to these 
I think the discussion has reinforced and crystallized my personal 
feeling on the subject:

- Services will have to start up listening to specific ports. Whether 
the port number is specified in an RFC, an SRV record or a config file 
on a dozen other hosts is in fact irrelevant to the fact that they have 
to start up knowing what port to listen to (unless they have write 
access to SRV).
- The "root gets to open ports < 1024" mechanism is harmful; there are 
ports < 1024 that need to be opened by non-root processes, and ports > 
1024 that need to be protected from "random programs".
- Conclusion 1: Hosts that care about separation of privileges need to 
be able to specify access rights on ports as part of their configuration 
- with "can be handed out to processes asking for a port" being one 
particular kind of access right.
- Conclusion 2: There is no reason for standards to uphold the 
distinction between <1024 and >1024 any more.

             Harald

---

From: Keith Moore <[email-masked]>
Date: Mon, 20 Mar 2006 11:51:04 -0500

> hosts, that's a recipe for disaster.

no, what's a disaster is to use source IP addresses or port numbers as
an indication of trustworthiness on any network that extends beyond a
single room.  the notion that you can "manage" significant numbers of
hosts to ensure their trustworthiness is delusional.

---

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

>> the concept of privileged access to shared system-critical 

Joe User is not running critical servers - at least not under windows.
And if he really does, he will not do it very long :)

That is what my log on echnaton says. Echnaton used to be dsl-router
and still is my (local) dns-server, my ftp server, mail-server and
ssh-server. Echnaton is automatically running a bunch of things and
sending reports.

Nothing is done as root, because I am the sysop.

ssh, ftp, dns and other nameservices (port 42) all use privileged
ports - sometimes not the ports you would guess :)

djbdns the part about daemon-tools and tcp can help you out of
the user-root crisis.

With XEON, VM, CoLinux and others you can run a couple of virtual
machines on your one real machine. Running each of your servers
on its own virtual hostdoes not cost you much cpu or memory.
But running each of your servers in its own virtual machine will
protect your real machine from getting hacked.

So we still have the privileged ports even if they are distributed
over virtual machines.

User me still has no reason to bind to a privileged port - and if
I do I am shure it is a bug.

It does not make sense removing bug protection only because
some unfamous collection of bugs cannot be fixed.

Believe me it is a dynamically changeing collection of bugs only.
It has no operating system structure built in. There is nothing
you can relibly run a server on. I tried to.

It does not make sense to bend rules breaking systems that do
work as servers. Windows is not a player in the server business.

Regards
Peter and Karin Dambier

---

From: Keith Moore <[email-masked]>
Date: Mon, 20 Mar 2006 12:00:40 -0500

> distinction between <1024 and >1024 any more.

I agree that the requirement on UNIX-like systems to be root in order
to bind to ports < 1024 is, in hindsight, a Bad Idea - but mostly
because of insufficient privilege granularity.   I also think that
trusting a source port as an indication of anything is a Bad Idea.

However, I do think that it's useful for there to be a range of port
numbers that are only bound to a socket if an application specifically
asks for one of those ports, as this would reduce the potential for
accidental conflicts between servers needing to listen to a well-known
port and servers for which any port would do.   And it would be
appropriate for standards to respect this convention and assign
well-known ports in the range of ports that would not be bound by
default.

I also think that it would be reasonable for an OS to require
privileges before it would allow an application to bind to certain
ports.  But those ports would need to be explicitly enumerated
somewhere, rather than merely being a range of numbers.

Keith

---

From: Ned Freed <[email-masked]>
Date: Mon, 20 Mar 2006 11:10:58 -0800 (PST)

> - Services will have to start up listening to specific ports.

And in some cases they have to be able to reconfigure to listen on new ports
without a full restart. This makes the "use root to start then drop it"
approach problematic in some cases.

> Whether

Yep.

> 1024 that need to be protected from "random programs".

Agreed.

> particular kind of access right.

Yes, and there also needs to be flexibility as to what entities such access
rights are given to. Neither a "this UID has these rights" or "this executable
has these rights" are adequate in all cases, for example.

> distinction between <1024 and >1024 any more.

Well, there may be some marginal cases left, but if there are they are
certainly a minority taste now and their future fate seems certain. And we're
definitely at the point where the <1024 approach carries more cost than
benefit, so I agree that the  time to drop the distinction in our processes is
now.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Mon, 20 Mar 2006 12:42:51 -0800 (PST)

> because of insufficient privilege granularity.

If by "insufficient privilege granularity" you mean root confers other access,
I agree. But while not critical, it would also be useful to have finer
granularity in terms of who gets access to what ports.

>  I also think that

You bet.

> well-known ports in the range of ports that would not be bound by

This also sounds reasonable.

> somewhere, rather than merely being a range of numbers.

Yes, it clearly needs to be fully configurable. Perhaps some of the existing
internal firewall configuration mechanisms could be reused here...

				Ned

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Mar 2006 01:05:16 +0100

It's been suggested to me that RFC 3639 might be
relevant to this thread.

    Brian

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Tue, 21 Mar 2006 01:56:47 +0100

> hosts to ensure their trustworthiness is delusional.

I don't see any contradiction in what you and I are saying, although I
would extend "single" to "handful".  in any case, it's getting off topic
for the issue at hand, so please continue discussion in private if you
care to respond.
-- 
Kjetil T.

---

From: Simon Leinen <[email-masked]>
Date: Tue, 21 Mar 2006 17:43:44 +0100

Stephane Bortzmeyer writes:
>> systems where you don't Joe-random-user to grab some port for a
>> well known service.

> is root on his PC and therefore this protection is almost useless.

Stephane, you are thinking of a different "security mechanism" based
on ports <1024 - the one used by the infamous Berkeley r* utilities to
decide whether to trust a client's credentials.  This mechanism
doesn't use well-known ports, but "ephemeral" ports <1024 on the
client side.  I think it is fairly much consensus that this kind of
mechanism has become useless years ago, for the reason you state.

What we are collecting input on is for which kinds of use (if any) a
privileged/well-known (as opposed to just IANA "registered") *server*
port makes sense.
-- 
Simon.

---

From: Peter Dambier <[email-masked]>
Date: Tue, 21 Mar 2006 18:30:51 +0100

>>is root on his PC and therefore this protection is almost useless.

It never was a protection against malevolent students but it still is
a protection against silly mistakes.

Just try "accidently" 'cd / ; rm -R *'

You know what I mean with silly mistakes. It makes a difference beeing
root or beeing user joe when you "accidently" execute the shown command.
Mistakes like that do happen.

> mechanism has become useless years ago, for the reason you state.

Behind closed doors and on virtual machines they still work remarkebly
well. It would be overkill to run an sshd on each of the virtual machines.
So would be logging in as root to directly access the virtual root
directories.

> privileged/well-known (as opposed to just IANA "registered") *server*

Some 70% of all server machines run operating systems that have a
notion of multiuser and of privileged user. Only servers are allowed
access to the privileged well-known ports. Allowing non-privileged
programmes access to the privileged ports leads to desaster

Moving the 1K border for well-known ports up to 16K would be nice in
the long run.

I agree, on the client only machines the distinction between well-known
and not so well-known ports does not make much sense. But those clients
cannot live without their servers and the servers would not survive
very long without their well-known ports.