Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-port-use-01.txt

From: [email-masked]
Date: Mon, 25 Feb 2013 09:05:57 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Transport Area Working Group Working Group of the IETF.

	Title           : Recommendations for Transport Port Uses
	Author(s)       : Joe Touch
	Filename        : draft-ietf-tsvwg-port-use-01.txt
	Pages           : 16
	Date            : 2013-02-25

Abstract:
   This document provides recommendations to application and service
   designers on how to use the transport protocol port number space to
   help in its preservation.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-use

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tsvwg-port-use-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-port-use-01

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Joe Touch <[email-masked]>
Date: Mon, 25 Feb 2013 09:18:41 -0800

Hi, all,

This version includes:

	- results of the discussion of user vs. system ports
	- populates the previous sections that were just bullets

It's a complete text version now. I'm still toying with the intro, and 
whether to move some of Sec 5 forward and some of the history later.

Suggestions or comments are welcome.

Thanks,

Joe

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 27 Feb 2013 18:35:08 +0000

Hi,

I gave this a quick read; here are some comments.

Lars

  High-level: Somewhere in this document, we should point out strongly
  that service names are available FCFS w/o IANA assignment, and are
  therefore MUCH easier to use when a service needs to be rolled out
  quickly.

Section 4., paragraph 4:
>       0-1023         0x03FF         Well-Known (a.k.a. 'system')
>       1024-49151     0x0300-0xBFFF  Registered (a.k.a. 'user')
>       49152-65535    0xC000-0xFFFF  Dynamic/Private

  1024 is 0x400

Section 5., paragraph 6:
>       http:51509//www.example.com/

  Actually, it would be http://www.example.com:51509/

Section 7.2., paragraph 0:
>  7.2. How Many Ports?

  You might want to add in this section that in the past, when the port
  number space was less crowded, multiple ports were assigned for one
  service, e.g., X11. However, that does not reflect current practice
  anymore, and the existence of such assignments in the IANA table does
  not constitute a precedent.

Section 7.3., paragraph 5:
>    >> Developers SHOULD NOT apply for system ports because the
>    increased privilege they provide is not always enforced.

  Developers CANNOT simply apply for system ports since RFC6335 was
  published. It very clearly says that the policy is "IETF Review" or
  "IESG Approval" only, and that 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.

Section 7.3., paragraph 7:
>    At some future date, it might be useful to deprecate the distinction
>    between system and user ports altogether, but merely avoiding system
>    ports would potentially waste only approximately 180 of 1024 values
>    (17%).

  You might want to add somewhere in this section that many services
  that need to bind to a system port go through great lengths in order
  to drop root privileges as soon as they have bound, in order to reduce
  their attack surface. So it's actually MORE secure to run on a port >
  1023.

Section 7.6., paragraph 7:
>    >> UDP multi-host services SHOULD use multicast rather than
>    broadcast.

  This suggestion isn't really about port use, and therefore maybe not
  in scope of this document.

Section 7.6., paragraph 8:
>    Designers should be very careful in creating services over
>    transports that do not support congestion control or error recovery,
>    notably UDP. There are several issues that should be considered in
>    such cases:

  Ditto. As much as I'd like a "how to design an application protocol"
  BCP, this one isn't it. Much of the UDP-specific stuff is also already
  discussed in more detail in RFC5405.

Section 7.7., paragraph 4:
>    Deployments that use ports before deployment complicate IANA
>    management of the port space. Keep in mind that this recommendation
>    protects both other parties and you; it helps ensure that your
>    desired number and service name are available when assigned. The
>    list of currently unassigned numbers is just that - *currently*
>    unassigned. It does not reflect pending applications, nor
>    applications that might arrive before yours. Waiting for an official
>    IANA assignment reduces the chance that your assignment will
>    conflict with another deployed service.

  You might want to say something about how long an IANA allocation
  typically takes to process.