Subject: [tsvwg] draft-ietf-tsvwg-port-use-00 abolish system/user distinction?

From: Bob Briscoe <[email-masked]>
Date: Thu, 6 Dec 2012 23:56:22 +0000

Joe,

Can you write down your rationale for removing the distinction 
between system & user ports?

I don't see why ceasing to allocate system ports will help. It's not 
clear whether you are trying to remove the false sense of security 
that system ports purport to offer, or whether you are trying to 
remove the higher bar to IANA allocation, both, neither, or what. 
There's too little written in the draft, on the list and around the 
bullets in your presentation of the draft to guess fully what you're 
driving at.

Not a criticism - we all have limited time to write what splurges out 
of our minds - I'm just trying to understand.

Cheers

Bob

At 00:08 05/06/2012, Joe Touch wrote:
>         - whether to deprecate the distinction between system and
>         user ports (or to do nothing at this time)

At 18:30 30/01/2012, Joe Touch wrote:
>         - discuss and/or make a recommendation about whether to
>         continue the system/user port space distinction
>         (IMO, the only useful way to do this is to suggest
>         that IANA cease allocating system ports)

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Eliot Lear <[email-masked]>
Date: Fri, 07 Dec 2012 06:40:06 +0100

> bullets in your presentation of the draft to guess fully what you're

I support the notion of combining system and user for the simple reason
that there is no technical difference between the two, there is no
meaningful additional security offered by system.  The distinction dates
back to the notion that non-privileged users couldn't open a port below
1024 and we knew all Internet hosts by name.

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 7 Dec 2012 10:45:49 +0000

Elliot,

I'm not saying I don't support removing the distinction in meaning 
(for the false sense of security reasons). I'm just saying there's 
nothing written about why it helps to achieve this if IANA no longer 
allocate ports under 1024.

I can't work out the reasoning for this, but I'm sure Joe has got 
one. What's written so far doesn't help anyone understand unless they 
already understand.

Bob

---

From: Joe Touch <[email-masked]>
Date: Fri, 07 Dec 2012 11:08:51 -0800

Hi, Bob, Eliot, et al.,

> 1024 and we knew all Internet hosts by name.

This was discussed at several IETFs before this doc was accepted as a WG 
item, so I thought there was context. The doc does need expanding on 
this, and I will do so in the next revision.

My view is that:

- the distinction has evolved to become meaningless, and thus treating 
any port as more trusted because of its assigned range is a bad idea (as 
Eliot points out above). Yes, there are plenty of systems that do 
continue to treat the two ranges as different, but enough others that 
don't that it seems a bad idea to continue to support the difference as 
meaningful.

Which is why I propose the following as an overall goal:

	The range 0...49151 will be known as Assigned ports.

	Port assignments will no longer distinguish between 'user',
	'system', 'well-known', and 'registered' subranges of Assigned
	ports.

If we do deprecate the difference between the ranges, we need to decide 
how to move forward.

First, regardless of how we move forward, IMO:

	Assigned ports should use the procedures from RFC 2780
	that apply to User ports.

There are two ways forward, given that goal (in the order of my preference):

a) this document can officially deprecate the distinction between User 
and System ports by declaring that IANA should cease further assignments 
from the System range

b) this document can suggest that users should not bother requesting 
system ports

c) this document can officially deprecate the distinction between User 
and System ports by merging the two and letting users pick any available 
port from the Assigned range

Of these options, I think (c) creates a "land rush" in the System space, 
and we don't have enough understanding of the impact on legacy protocols.

(a) is the safest, since it merely requires that new services be 
designed in a way that assumes that they could be run by any user on any 
system - which, these days, seems like a reasonable recommendation.

(b) is a way to circumvent the issue without deprecating the User/System 
distinction, and IMO just continues to ignore the current situation

Thoughts?

Joe