Subject: [tsvwg] port scarcity - WGLC for draft-ietf-tsvwg-port-use-04

From: "Black, David" <[email-masked]>
Date: Tue, 27 May 2014 20:04:14 -0400

Joe,

<WG chair hat OFF>

> > But, regardless, given that you agree that there is no evidence for the
> > scarcity, the whole reason for this document seems to fall apart.
> 
> Scarcity is a relative measure. There are only 16 bits of port space,
> and yes, it's only 11% used. But we've turned away dozens of requests
> for 10s-100s of ports, and cut a large number of requests for multiple
> ports down to one or two.

Are these out-of-line requests (mostly non-IETF, if I understand correctly)
the primary motivation for the scarcity discussion?

If so, could the scarcity discussion be somewhat more focused on requests
that are clearly asking for entirely too many ports?  It feels like one or
two at a time is not a major cause for concern, but I clearly understand the
problems with requests for 10s-100s.

RFC 6335 already says (section 7.2):

   o  IANA strives to assign only one assigned port number per service
      or application.

	[Note on security snipped - belongs in other thread.]

   o  IANA strives to assign only one assigned port number for all
      variants of a service (e.g., for updated versions of a service).

Perhaps a reminder of that plus documentation of the practices that
the port reviewers are currently following would be a good starting
point.

</WG chair hat OFF>

Thanks,
--David

> -----Original Message-----
> From: tsvwg [mailto:[email-masked]] On Behalf Of Joe Touch
> Sent: Tuesday, May 27, 2014 6:19 PM
> To: Paul Hoffman
> Cc: [email-masked]
> Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June)
> 
> 
> 
> On 5/27/2014 2:42 PM, Paul Hoffman wrote:
> > On Tue, May 27, 2014 at 11:41 AM, Joe Touch <[email-masked]
> > <mailto:[email-masked]>> wrote:
> >
> >
> >
> >     On 5/26/2014 1:50 PM, Paul Hoffman wrote:
> >
> >         This draft, when taken in light of RFC 6335, is completely
> >         unnecessary.
> >         If it is moved forward at this time, it will cause harm to the
> >         Internet
> >         for absolutely no purpose.
> >
> >         There is no evidence that that port numbers are actually scarce.
> >
> >
> >     Although that's true (as already noted in RFC6335, and should be
> >     cited in this doc too) it's only because of the 1:1 feedback that
> >     the review process has been providing.
> >
> > Is there any evidence to support the statement that feedback has changed
> > this for new IETF protocols? If so, it should certainly be cited.
> 
> IANA didn't maintain information on assignments per year; I've gotten
> them for the time since I've helped manage the assignments.
> 
> There were a few distinct assignment periods and associated policies:
> 
> 	- prior to ICANN, Jon Postel managed them largely as we do now,
> 	treating them as something to conserve as much as we knew;
> 	some apps were assigned ranges (notably X Windows) because
> 	we didn't know better at the time
> 
> 	- after ICANN (1998), but before the expert review process was
> 	active (2008)
> 
> 	- active expert review process (2008-present)
> 
> Here is the data from the recent years, measured in requests. Not all
> request are for a single assignment. As you can see, the number dropped
> roughly in half since 2008. I don't have more recent statistics:
> 
> Year	submitted	resolved	%
> 2012	200	        80	       40.00%
> 2011	187	        88	       47.06%
> 2010	210	        118	       56.19%
> 2009	209	        149	       71.29%
> 2008	257	        166	       64.59%
> 
> I've been trying to get some information about the historical assignment
> rate, but it's slow-going. The rate of assignment approvals has dropped
> since we started putting this advice in place.
> 
> However, again, this is NOT intended to be new advice; this is simply
> the same style of advice we have been giving on case-by-case basis to
> applicants. In the vast majority of cases, applicants have appreciated
> getting the feedback and it has led to better protocol design IMO. There
> are some corner cases, as there would be with *any* process.
> 
> > But, regardless, given that you agree that there is no evidence for the
> > scarcity, the whole reason for this document seems to fall apart.
> 
> Scarcity is a relative measure. There are only 16 bits of port space,
> and yes, it's only 11% used. But we've turned away dozens of requests
> for 10s-100s of ports, and cut a large number of requests for multiple
> ports down to one or two.
> 
> > The
> > advice of "you should consider multiplexing one one port" is fine, of
> > course; the theme of the first half of the document that the advice
> > comes from scarcity is not if there is no scarcity.
> 
> Your argument seems to stem from the impression that this doc is
> claiming that something changed that necessitates new, urgent conservation.
> 
> The reality is that the only reason we've been able to keep down to 11%
> of use is because of ongoing conservation. 16 bits is not a large space.
> 
> >     The intent of this doc is to provide broader advice, in a single
> >     place, that's been vetted by the entire transport community.
> >
> >
> > A BCP is not "broader advice": it is a statement of what the IETF
> > believes to have been proven as best practice. Much of the advice in the
> > document ("systems might require a single port assignment, but rarely
> > require multiple ports") cannot be proven as a best practice. It is a
> > practice to consider, but it is not "best".
> >
> >     ...
> >
> >         The draft presumes that preservation of port numbers, even when
> >         there is
> >         in fact no significant scarcity, is more important than letting
> >         Application and Security Area WGs determine what their ports
> >         needs are.
> >
> >
> >     There is no aspect of this doc that overrides the current assignment
> >     process, which includes expert review for requests outside the IETF
> >     (the bulk of the requests, FWIW) and RFC process for those inside WGs.
> >
> >
> > That statement is orthogonal with the statement I made. This draft keeps
> > hammering at the scarcity as a justification for giving advice; the RFC
> > says there is no scarcity; thus, this document updates the RFC. Removing
> > all discussion of scarcity and dropping the intended level of this
> > document to Informational would go a long way to fixing that problem.
> >
> >
> >     ...
> >
> >         The information about applications that use one fixed port and then
> >         dynamic ports ignores experience that has revealed significant
> >         problems.
> >
> >
> >     It's still in widespread use in FTP, SIP, etc. The challenges of
> >     doing so are already noted.
> >
> >
> > "Noted" but still pushed in the name of scarcity. A less opinionated
> > discussion of the problems that FTP and SIP have encountered, and a
> > comparison to protocols that don't have those problems because they use
> > fixed ports, would be more informational.
> >
> >
> >         Even if there were real scarcity (which the BCP shows that there
> >         isn't),
> >
> >
> >     FWIW, because these rules have been informally encouraged for decades...
> >
> >
> >         it is impossible to weigh the needs of port scarcity against the
> >         need to
> >         create less fragile protocols.
> >
> >
> >     I'll certainly highlight better the issue of in-band identifiers and
> >     protocol fragility.
> >
> >
> > Then why even do this at all? That is, if there really is no scarcity,
> > what value is this document? I have not heard application or security
> > developers say "we don't know where to find examples of protocols that
> > use ports in interesting ways, let's look for an RFC that lists them".
> > Once the scarcity argument is stripped out, and even if the firewalls
> > discussion is brought up to date (it uses examples that are about a
> > decade out of date), the meat of the document is "you can design your
> > protocol's use of ports however you want". This doesn't seem useful, and
> > still could be harmful if used as a blunt object during IANA review.
> >
> > --Paul Hoffman
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 27 May 2014 17:09:48 -0700

> the primary motivation for the scarcity discussion?

Yes.

> problems with requests for 10s-100s.

That's true, but it's also the case that a lot of applicants request 
ports that aren't needed at all. We don't recommend against any new 
protocol; we just ask whether existing services have been considered, 
and encourage designs that are easier to manage and debug (i.e., using a 
single port rather than one for each component of a complex system).

> the port reviewers are currently following would be a good starting

That's basically how this document came into being, FWIW. It's certainly 
useful to point back to this advice to link together the two docs better.

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 May 2014 14:18:13 +1200

> useful to point back to this advice to link together the two docs better.

As Joe said on a different sub-thread

> Scarce is relative, of course. Right now I count 5847 TCP and 5570 UDP numbers, but the total range is 16 bits, and that's not considered a large range overall. 

Indeed. These are a *significant* fraction of 49151, so even if a
naive extrapolation suggests 85 years to run, I think it would
be irresponsible not to apply prudent stewardship. That will be
more effective if we publish design advice as well as rules.

(The Abstract and Introduction could usefully point out that
this draft augments the advice already given in RFC 6335).

   Brian