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

From: Joe Touch <[email-masked]>
Date: Wed, 02 Jan 2013 13:50:24 -0800

Hi, all,

Any thoughts on this, given the context below?

I'd like to have the input of others on this list before updating the 
draft on this point.

Thanks,

Joe

On 12/7/2012 11:08 AM, Joe Touch wrote:
> Hi, Bob, Eliot, et al.,
>
> On 12/6/2012 9:40 PM, Eliot Lear wrote:
>>
>> On 12/7/12 12:56 AM, Bob Briscoe wrote:
>>> 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.
>>
>> 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.
>
> 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
>

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 3 Jan 2013 09:00:21 +0000

Hi,

On Dec 7, 2012, at 20:08, Joe Touch <[email-masked]> wrote:
> 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

RFC6335 already raises the bar for system port allocations:

   o  Ports in the System Ports range (0-1023) are also available for
      assignment through IANA.  Because the System Ports range is both
      the smallest and the most densely assigned, the requirements for
      new assignments are more strict than those for the User Ports
      range, and will only be granted under the "IETF Review" or "IESG
      Approval" procedures [RFC5226].  A request for a System Port
      number MUST document *both* why using a port number from the
      Dynamic Ports range is unsuitable *and* why using a port number
      from the User Ports range is unsuitable for that application.

So essentially, the system port range has become reserved for the IETF. Do we need to do anything more?

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

Well, it should say that requests need to undergo the needed IETF review phases.

> 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.

I don't like (c) either. I don't think the land rush is going to happen (because of RFC6335), but because it might affect implementations that do treat the ranges differently. Would like to not affect deployed code.

> (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.

I think RFC6335 has basically resulted in option (a) already, with the notable exception that the IETF can still assign system ports. I think that's good.

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

(b) has also essentially been established by 6335 - requests for system ports must undergo IETF Review and therefore be sufficiently documented in an ID so that this review can happen. IANA cannot assign them directly anymore.

Lars

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 03 Jan 2013 09:02:47 +0000

On 02/01/2013 21:50, Joe Touch wrote:
...
>>      that apply to User ports.

As far as I can tell, RFC 2780 is completely superseded by
RFC 6335 for this purpose, and that's what the IANA registry
says too. The draft would have to formally update 6335.

If I read your statement as "Assigned ports should use
the procedures from RFC 6335 that apply to User ports."
it would mean "IETF Review", "IESG Approval", or "Expert Review".
At the moment, Expert Review is not allowed for ports 0-1023.

>> port from the Assigned range

s/pick/request/

>> and we don't have enough understanding of the impact on legacy protocols.

As far as I can see, the only real-world effect of your proposal
would be to allow ports 0-1023 to be assigned by Expert Review,
if and only if we pick option (c). If we pick (a) or (b) we simply
waste something like 280 ports without knowing why.

Without a proper understanding, I don't see any real basis for
deciding whether there's any benefit to a change. In fact I'd go
further: if we can't pick (c) the whole exercise seems a bit pointless,
since we don't make any change in the real world that I can see.

    Brian

---

From: [email-masked]
Date: Thu, 3 Jan 2013 10:19:14 -0000

It seems probable that some systems (legacy, specific platforms) may
differentiate the two port ranges - perhaps because of legacy
implementations or because they have a different user/process model,
different to mainstream OS. (c) below would conflict with this existing
use.

I can see the merits in at least (b) advising users to not request (and
hence IANA to generally not accept) requests to allocate to this range,
and explaining why.

If there are ANY "potential" examples of cases where new protocols may
benefit from having ports in this range that are known at the moment,
people do need to speak on this list, or tell the author/ tsvwg chairs.

Gorry

---

From: Joe Touch <[email-masked]>
Date: Thu, 03 Jan 2013 10:50:49 -0800

> says too. The draft would have to formally update 6335.

RFC6335 reiterates the process in RFC2780; it doesn't create new policy 
on this matter.

Depending on the decision, this doc might have to update 6335. I.e., 
arguably neither (a) nor (b) need to update 6335 since they don't change 
the application process so much as tell IANA or users what to do.

> At the moment, Expert Review is not allowed for ports 0-1023.

Yup.

>>> port from the Assigned range

Yes.

> if and only if we pick option (c).

Right.

> If we pick (a) or (b) we simply

Well, we can explain why. And yes, we would lock out those available 
ports from further use.

> since we don't make any change in the real world that I can see.

All of them make a change. I'm not sure why you don't think that's the case.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 03 Jan 2013 11:05:04 -0800

Hi, Gorry,

> different to mainstream OS. (c) below would conflict with this existing

Yes. However, the current distinction is meaningless in some OSes as 
well; the point of (c) is to recognize that the distinction is already 
not widely enforced.

> people do need to speak on this list, or tell the author/ tsvwg chairs.

Here's how many have been assigned in the past few years:

	2007	2
	2008	3
	2009	0
	2010	6
	2011	2
	2012	8

I.e., we still do get requests. There are people who still want numbers 
in that range due to perceived security, but IMO that rationale is 
incorrect. If that's the only reason, then IMO there's no reason to 
distinguish those numbers as different.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 03 Jan 2013 11:15:46 -0800

Hi, Lars,

> So essentially, the system port range has become reserved for the IETF. Do we need to do anything more?

I just posted a summary of how many ports have been assigned in the past 
few years to the system range. The procedures above are what was 
informally required by IANA during that period anyway, and so we 
continue to receive requests and approve assignments based on the idea 
that this range is desired.

> Well, it should say that requests need to undergo the needed IETF review phases.

Yes, but in this case we'd be recommending that the IETF review phase 
isn't relevant; the point is that this range isn't treated differently 
in enough OSes that it's not useful to treat those ports as disgintuished.

> I don't like (c) either. I don't think the land rush is going to happen (because of RFC6335),

(c) implies updating 6335 to allow "expert review" only, as with the 
user ports now.

> but because it might affect implementations that do treat the ranges
> differently. Would like to not affect deployed code.

Right, but the concern is that there are two sets of widely deployed code:

	- code that treats system ports as privileged, e.g., requiring
	"root" access to connect to those ports

	- code that does not treat those ports as privileged

IMO, it's a security risk to continue to expect these ports as being 
privileged, and we should cease propagating that misconception.

> I think RFC6335 has basically resulted in option (a) already, with
> the notable exception that the IETF can still assign system ports. I
> think that's good.

As I noted in my other post, (a) was essentially in effect for the past 
6 years (at least), and that resulted in continued assignments 
(averaging 3/year).

Note - this isn't an issue about running out of those ports. Given 270 
available (Brian's number), we'd have 90 years left, which is roughly 
when the other ports run out at the current rate of assignment too.

> (b) has also essentially been established by 6335 - requests for system ports must undergo IETF Review and therefore be sufficiently documented in an ID so that this review can happen. IANA cannot…

I disagree; again, we've had 3/year. That's not based on a 
recommendation that users shouldn't bother with that range.

Joe

---

From: Eliot Lear <[email-masked]>
Date: Sat, 05 Jan 2013 10:46:42 +0100

Joe,

I like your summary.  I would be satisfied with (a) or (c) with the
understanding that with regard to (c) the expert reviewer has the final
choice as to what port to use – and not the applicant, and that the
expert reviewer will use (a) as a guide unless there is very good reason
to do otherwise.  Yes, I'm hedging slightly, but I just don't want
someone writing stupid code that says that new protocols in that space
are somehow unauthorized in some way (avoid a 240/4 situation).  You'd
think that'd be difficult with a range that is half consumed, but I
wouldn't underestimate some implementers...

Eliot

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 7 Jan 2013 10:23:49 +0000

Joe,

Tx for yr explanation. Previously the doc merely 
stated option a), without saying why, and I read 
all the discussion on the list going back to the 
beginning and couldn't find any reason why.

I guess avoiding a landrush might be a valid 
concern - a bit like once most of the gold has 
been found, removing all controls on prospecting 
and trying to declare that gold is no longer a 
precious metal. If gold really is no longer a 
precious metal, it wouldn't matter.

Similarly, given system ports aren't special, 
opening up the allocation space shouldn't matter. 
However, we all know people (and implementers ;) are irrational.

Like Eliot, I have no strong pref betw a) and c). But b) is too weak.

If we do choose a), we should consider a feasible 
transition strategy at a later stage to allow the 
unallocated ports 0-1023 to be allocated. Eg. 
plan to open 0-1023 up for allocation after a 
couple of years while ports are still plentiful, 
rather than waiting until they become scarce, 
which will just precipitate a bigger landrush at some later date.

Bob

At 09:46 05/01/2013, Eliot Lear wrote:
>choice as to what port to use  and not the applicant, and that the

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Joe Touch <[email-masked]>
Date: Thu, 17 Jan 2013 16:57:51 -0800

Hi, Bob, Eliot, et al.,

On 1/7/2013 2:23 AM, Bob Briscoe wrote:
> Joe,
>
> Tx for yr explanation. Previously the doc merely stated option a),
> without saying why, and I read all the discussion on the list going back
> to the beginning and couldn't find any reason why.
>
> I guess avoiding a landrush might be a valid concern - a bit like once
> most of the gold has been found, removing all controls on prospecting
> and trying to declare that gold is no longer a precious metal. If gold
> really is no longer a precious metal, it wouldn't matter.
>
> Similarly, given system ports aren't special, opening up the allocation
> space shouldn't matter. However, we all know people (and implementers ;)
> are irrational.
>
> If we do choose a), we should consider a feasible transition strategy at
> a later stage to allow the unallocated ports 0-1023 to be allocated. Eg.
> plan to open 0-1023 up for allocation after a couple of years while
> ports are still plentiful, rather than waiting until they become scarce,

Sure - I'll update the doc accordingly.

Thanks for the discussion.

Joe