Recommendations on Using Assigned Transport Port Numbers
draft-ietf-tsvwg-port-use-11

The most recent revision addresses the two remaining points from my Discuss. Thanks to the author for the (somewhat lengthy) discussion that resulted in the changes.

I have also reduced my list of Comments according to this most recent revision and our discussions.

[Please recall that Comments are my voiced opinions, but are not mandatory. Please reach agreement with your AD on what needs to be done to the document.]

---

I agree with Ted's Discuss about secure and insecure variants on 
different port numbers.

RFC 6335 says

      Note: At the time of writing of this document, there is no IETF
      consensus on when it is appropriate to use a second port for an
      insecure version of a protocol.

I don't see that Section 7.4 of this document has established that
consensus, and I believe that there are good reasons to distinguish
secure and insecure protocol versions (esepecially with legacy, insecure
protocols) by use of separate port numbers.

---

[This item removed from my Discuss]

I think that the "guiding principle" in 6.1 that says...

      o  Copies of an existing service can be differentiated by using
         different IP addresses, either on different hosts or as
         different real or virtual interfaces (or even operating
         systems) on the same host.

... describes an option, but it is wrong to suggest it as a solution.
The main thrust of the document says that it is wrong to include a 
demultiplex reference at the transport layer when what is being
multiplexed is really at the application layer (or at last at the level
of the payload of the transport protocol). Yet this suggested remedy
actually pushes the demultiplex identifier to the network layer. That
really is not a good thing to recommend.

...Further to email discussion with the author, I think that this is describing
a situation where copies of a host are being made, not copies of a service.
It is not a significant Comment, but I feel that this bullet is distracting from
the main list of suggested solution.

I agree with Adrian's DISCUSS

Thanks for addressing my DISCUSS!

---

I think I may have some overlapping comments with Barry, but I wrote this before I saw his comments, so my apologies.

-- Sec 5:
"Port numbers can also be useful for other purposes."

I would suggest s/useful/used/ because whether the purposes listed in the previous paragraph (e.g., monitoring, blocking, etc. based on port number) are considered "useful" is in the eye of the beholder.

-- Sec 7.4:
The term "security" is really vague. It would help to define what is meant by "security" or "secure service."

-- Sec 7.4 and 7.5:
Both of these sections contain recommendations that are good, but seem out of place in this document unless they could be made more specific to port use. The ones that jumped out at me are:

   >> New services SHOULD support security, either directly or via a
   secure transport such as TLS [RFC5246].

   >> Insecure versions of new or existing secure services SHOULD be
   avoided because of the new vulnerability they create.
   
   >> Version support SHOULD be included in new services.

I would say to either remove these or add in the context of what they have to do with port number assignment (e.g., "Version support SHOULD be included in new services rather than relying on different port number assignments for different versions.")

-- Sec 7.7:
"Deployments that use port numbers before deployment complicate IANA
   management of the port number space."

I think this is supposed to say "before assignment" rather than "before deployment."

-- Sec 7.8:
""Squatting" describes the use of a number from the assigned range in
   deployed software without IANA assignment. It is hazardous because
   IANA cannot track such usage and thus cannot avoid making legitimate
   assignments that conflict with such unauthorized usage.

   Such "squatted" port numbers remain unassigned, and IANA retains the
   right to assign them when requested by applicants."

This is a little confusing -- is the first sentence supposed to say "unassigned range"? If not, what is the assigned range, and why is IANA said to retain the right to assign numbers that are already assigned? I would have thought squatting would be understood as using unassigned numbers in the system and user ranges.

"In
   particular, any unassigned code from the assigned ranges will be
   assigned by IANA, and any conflict will be easily resolved as the
   protocol designer's fault once that happens (because they would not
   be the assignee). This may reflect in the public's judgment on the
   quality of their expertise and cooperation with the Internet
   community."

This seems a little over-the-top to me. I would suggest:

"IANA may assign any code from the system or user ranges to applicants that meet all of the relevant criteria, and is not obligated to take into consideration the existence of squatters when doing so. Squatting is viewed as uncooperative behavior in the Internet community."

Thanks for quickly addressing my DISCUSS points, two of which are cleared and two of which are now comments here:

-- Section 7.4 --
   >> New services SHOULD support security, either directly or via a
   secure transport such as TLS [RFC5246].

In this context, "security" is too vague a term: what, exactly, does "SHOULD support security" mean?  Are you talking about authentication?  Access/authorization controls?  Confidentiality?  Specifically, encrypted communication?  I think you mean the last.

<<
Joe Touch responds:
It would be useful to explain.
Security depends on the service being offered; for some, encryption, integrity protection, and source identity are all expected, but for many services only a subset of these might be relevant.
>>

We should add such an explanation.

-- Section 7.4 --
   >> When simultaneously requesting both a secure and an insecure
   port, strong justification MUST be provided for the insecure port.
   Precedent (citing other protocols that use an insecure port) is not
   strong justification by itself.  A strong case for utility of the
   insecure service is REQUIRED for approval of the insecure port.

This seems significantly stronger than what RFC 6335 said, and this point was hotly debated in the development of that document.  RFC 6335, Section 9, says this:

   Services are expected to include support for security, either as
   default or dynamically negotiated in-band.  The use of separate
   service name or port number assignments for secure and insecure
   variants of the same service is to be avoided in order to discourage
   the deployment of insecure services.

As this document does not update 6335, I don't see how the MUST and the REQUIRED are appropriate.  But perhaps I can be convinced by some discussion.

Joe Touch responds:
<<
Again, one doc applies to IANA, the other to protocol designers. RFC6335 explains why IANA should avoid such an assignment; this doc explains that a designer is expected to justify the need in an request to IANA.

It might be useful, as a result, to remove the 2119 language, e.g., to write this from the perspective of advice to the applicant:

     >> When simultaneously requesting both a secure and an insecure
     port, strong justification is expected for the utility and safety
     of a separate insecure port.
     Precedent (citing other protocols that use an insecure port) is not
     strong justification by itself.
>>

The rest of these are non-blocking, but please consider them -- many are meant to clarify the text, and I hope they succeed in that.

In three places:

-- Abstract --
   This document provides recommendations to application and service
   designers on how to use the transport protocol port number space.

-- Section 1 --
   It also provides specific
   recommendations to designers on how to use assigned port numbers.

-- Section 2 --
   In this document, the characters ">>" preceding an indented line(s)
   indicates a compliance requirement statement using the key words
   listed above.

First, recommendations on how to use *port number space* is not the same as recommendations on how to use *assigned port numbers*.  I interpret the former as recommendations about making requests for port numbers, and the latter as recommendations about use of the port numbers after they've been assigned.  These should be worded consistently.

Second, recommendations, whichever type of recommendations they be, are not the same as compliance requirements.  I read the former as suggestions, and the latter as, well, requirements.  If the document is giving requirements that cover port-number requests -- and it is, complete with MUSTs -- it needs to clearly say that up front, and get rid of the "recommendations" stuff (or say both, that there are both requirements and recommendations here).

-- Section 5 --

   Consider a user wanting to run a web server. That service could run
   on any port number, provided that all clients knew what port number
   to use to access that service at that host. Such information can be
   distributed out-of-band, e.g., in the URI:

      http://www.example.com:51509/

It's a fine point, but having the port number in the URI doesn't actually distribute it "out of band" (which doesn't need hyphens in this context).  I would say, "Such information can be explicitly distributed -- for example, by putting it in the URI:".

   IANA assigns port numbers so that Internet endpoints do not need
   pairwise, explicit coordination of the meaning of their port
   numbers. This is the primary reason for requesting assigned port
   numbers with IANA - to have a common agreement between all endpoints
   on the Internet as to the default meaning of a port number.

This only says half of it, and omits a very important piece, I think.  May I suggest this?:

NEW
   IANA assigns port numbers so that Internet endpoints do not need
   pairwise, explicit coordination of the meaning of their port
   numbers. This is the primary reason for requesting assigned port
   numbers with IANA - to have a common agreement between all endpoints
   on the Internet as to the default meaning of a port number, and to
   provide the endpoints with a default port number for a particular
   protocol or service.
END

   >> Each port requested MUST be justified as independently necessary.

This is a fair statement, and yet I worry that including "necessary" may result in arguments between protocol designers and port experts about what is and isn't "necessary", and what the community's consensus is on it.  I'm not sure how to minimize that.  I'd say "MUST be independently justified," which does get the point you want (the independent justification) without using the loaded word "necessary".  I'd prefer that wording, though I admit that it can just as easily result in the same arguments.

-- Section 6.1 --

      o  Copies of an existing service can be differentiated by using
         different IP addresses, either on different hosts or as
         different real or virtual interfaces (or even operating
         systems) on the same host.

As a guiding principle for protocol designers, this worries me: it's an operational point, not a point of protocol design.  I'd have no objection if this were explicitly cast as an operational suggestion.

      o  Services requiring varying performance properties can already
         be supported using separate endpoint associations (connections
         or other associations), each configured to support the desired
         properties.

I can't figure out what you mean here.  Do you have an example, or can you tweak the explanation?

-- Section 7 --

   7. How to Use Assigned Port Numbers

   Port numbers are assigned by IANA by a set of documented procedures
   [RFC6335]. The following section describes the steps users can take
   to help assist with the use of assigned port numbers, and with
   preparing an application for a port number assignment.

In both the title and the paragraph, you refer to the "use" of "assigned port numbers", and yet the entire section talks about getting port assignments, not about using the port numbers after they're assigned.  I suggest this instead:

NEW
   7. Considerations for Requesting Port Number Assignments

   Port numbers are assigned by IANA by a set of documented procedures
   [RFC6335]. The following section describes the steps designers can
   take to help assist with the responsible assignment of port numbers,
   and with preparing an application for a port number assignment.
END

-- Section 7.1 --

      o  Port numbers are not intended for indicating different service
         versions. Version differentiation should be handled in-band,
         e.g., using a version number at the beginning of an
         association (e.g., connection or other transaction). This may
         not be possible with legacy assignments, but all new
         assignments should incorporate support for version indication.

Is this meant to say "but all new protocols should incorporate support for version indication."?  It's not the assignment that does that.

   Some users may not need assigned port numbers at all

Is this meant to say "some uses may not" (or "some protocols", but not "some users")?

-- Section 7.2 --

   There are a
   variety of known ways to reduce port number use. Although some may
   be cumbersome or inefficient, they are always preferable to
   consuming additional port numbers.

1. I think "reduce port number consumption" might be a better way to say what you mean here.

2. I don't think "always preferable" is consistent with the consensus on RFC 6335.  I would accept "usually preferable", but not something as strong as "always".

   Although
   automatic configuration protocols have been proposed and developed
   (e.g., STUN [RFC5389], TURN [RFC5766], and ICE [RFC5245]),
   application and service designers cannot yet rely on their presence.

I wouldn't call STUN, TURN, and ICE "automatic configuration protocols".  I'd refer to them as "NAT traversal protocols".

-- Section 7.3 --

   Would a TCP (or other transport
   protocol) port number assignment be useful by itself?  If so, a TCP
   (UDP) port number can be assigned whose port number is already (or
   can be subsequently) assigned to a different transport protocol.

I'm not sure what you're getting at here.  Are you saying that if you need a TCP port, you might pick one where the UDP port of the same number is (or can be) used for something else, and vice versa?  If so, I don't think it says that at all clearly.  In any case, can you please rephrase this to make it clearer?

   >> Developers SHOULD NOT apply for System port numbers because the
   increased privilege they are intended to provide is not always
   enforced.

Hm.  This sounds odd to me: it seems that it's setting up a feedback loop that's self sustaining.  You might want a system port number to get protection against running on that port by non-root.  But you won't always get that protection.  So you shouldn't ask.  So no one asks, and so no one gets the protection even when it's available.

Do you think this works as well for you?:

NEW
   >> Developers SHOULD request User port numbers, to avoid using
   the more limited System port number space.  Consider that the
   increased protection that System ports are intended to provide
   is not always enforced.
END

I would also move that paragraph down one, so that it's after the "Even when developers" paragraph.

-- Section 7.4 --

   >> Security SHOULD NOT rely on port number distinctions alone; every
   service, whether secure or not, is likely to be attacked.

I find this underspecified.  I don't know what I should be doing about this.  As in the DISCUSS, "security" is a vague term, and I don't know how to determine whether I've met this requirement, nor how to assess whether my situation is suitable one for not following it.

   Optional security can penalize performance, requiring additional
   round-trip exchanges before a connection or other association can be
   established. As discussed earlier, port numbers are a critical
   resource and it is inappropriate to consume assignments to increase
   performance. As a result, the need for separate ports for both
   secure and insecure variants is not justified merely for performance

Where was this discussed earlier?  The only thing I see related to performance that was discussed earlier is that it's not appropriate to have different ports to support different performance levels.  That's not the same thing that you're talking about here.  I agree with the conclusion (in the final sentence I quote).

   - either for the connection or association establishment performance
   or differences in data performance between secure and insecure
   variants.

I can't parse this.  Are there words missing or some such?

   Note however that a new service might not be eligible for IANA
   assignment of both an insecure and a secure variant of the same
   service, and similarly applications requesting assignment for both
   an insecure port number for a secure service might not be
   appropriate.

I'm having trouble with this one also; I can't parse what comes after the comma.  Maybe split the sentence into two, and rephrase?

-- Section 7.5 --
How can this apply retroactively to current assignments?  And "the multiple versions" should probably lose the "the".

-- Section 7.6 --
Spencer has been picking on the use of 793 as a reference for TCP.  Spencer, is 793 an acceptable reference for TCP here?

It would probably be better to attach the references to their protocols, rather than to have them in a group at the end of the list.

   Originally, IANA port number assignments were concurrent for both
   UDP and TCP; other transports were not indicated.

Total nit: I think this sentence doesn't work well with a semicolon, and would prefer changing the ";" to ", and".

   When the services differ, their service names and descriptions
   should reflect that difference.

I had a little trouble with this and the discussion leading up to it, which I think can be fixed by saying explicitly that in this case, it's OK (perhaps even encouraged) to use the same port, but different service names.  Perhaps something like this?:

NEW
   When the services differ, it may be acceptable or preferable
   to use the same port number, but the service names and
   descriptions should be different, reflecting the differences
   in the services.
END

   The following convention has been used by IANA
   for several years to distinguish discovery services, such as are
   used to identify endpoints capable of a given service:

   >> Names of discovery services SHOULD use an identifiable suffix;
   the suggestion is "-disc".

It reads oddly to have "the following convention" point to a normative requirement, and not just to the convention.  Again, a nit, but I think it would read better like this:

NEW
   IANA has, for several years, used the suffix "-disc" in service
   names to distinguish discovery services, such as are used to
   identify endpoints capable of a given service.

   >> Names of discovery services SHOULD use an identifiable suffix;
   the suggestion is "-disc".
END

   because IP routers do not forward "all nodes" (all 1's, i.e.,
   255.255.255.255 for IPv4) broadcasts and have not been required

The phrase << "all nodes" broadcasts >> needs to stay together, and splitting it with the explanation made me trip over it.  I suggest moving the word "broadcasts" before the parenthesized bit.

   >> Services SHOULD NOT use UDP as a performance enhancement over
   TCP, i.e., to circumnavigate TCP's congestion control.

Is circumventing congestion control the only possible performance enhancement here?  This sentence really makes one ask whether "i.e." is correct, or you mean "e.g.", and I think it'd be better done one of these ways:

If you mean to say that congestion control is the only reason:
NEW
   >> Services SHOULD NOT use UDP to enhance performance by
   circumventing TCP's congestion control.
END

If there might be other performance-enhancement reasons:
NEW
   >> Services SHOULD NOT use UDP as a performance enhancement over
   TCP.  For example, do not use UDP to circumvent TCP's congestion
   control.
END

(The right word is "circumvent", not "circumnavigate".)

-- Section 7.7 --

   Applications made through Internet Draft / RFC publication (in any
   stream)
...
   When a document has been approved for
   publication and proceeds to IESG Approval

The first sentence tries to make this stream-independent, but the "IESG Approval" later in the paragraph is specific to the IETF stream.  Because you already say "approved for publication", you can just omit the "and proceeds to IESG Approval" phrase.

-- Section 7.8 --

   Such "squatted" port numbers remain unassigned, and IANA retains the
   right to assign them when requested by applicants.

It might be good to be completely clear and say "requested by other applicants," lest readers think you mean to be talking about when the squatters make an application later.

The last paragraph in this section starts by encouraging squatters to make registrations now, but then shifts to a discouraging tone.  I wonder if you mind changing the tone a little, maybe changing the idea of "not justified" to something more like "unable to accommodate".  Perhaps like this?:

NEW
   Designers who are using such
   port numbers are encouraged to apply for an assignment.  Every
   effort will be made to accommodate such requests, though even with
   widespread de-facto use, if the port number has already been
   assigned to another applicant such accommodation might not be
   possible.  Note also that the application must pass review by the
   IANA Ports Expert Review team, as must any port application.
END

-- Section 8 --

   The port number alone should not be used
   to avoid denial of service or firewall traffic because their use is
   not regulated or validated.

To "avoid ... firewall traffic"?  What's that mean?

I think you mean "to avoid denial-of-service attacks or to manage firewall traffic", yes?  And then what is the "they" in "their use"?

I have many of the same questions as Barry.

   At some future date, it might be useful to deprecate the distinction
   between System and User port numbers altogether. Services typically
   require elevated ('root') privileges to bind to a System port
   number, but many such services go to great lengths to immediately
   drop those privileges just after connection or other association
   establishment to reduce the impact of an attack using their
   capabilities. Such services might be more securely operated on User
   port numbers than on System port numbers.

operationaly we already have dropped the distinction. there is not practical distiction for a new service allocated out of the remaining 180 system ports and one allocated out of the user ports so we might as well treat the port space as flat.

Comments:

Thanks for your work on this draft and addressing my and other ADs prior discusses and comments.  I'll just leave the one comment below as Alissa's discuss may not have been addressed yet.  I'll be interested to see any new text on it.

For what it's worth, I read 6.2 as informational background and think the text is helpful.  Alissa has a discuss on this, so if the text is changed, I'd be interested to see what the suggested changes would be so that the draft still conveys the helpful information (which she was not opposed to in the discuss).  I've configured hundreds of firewalls and what is described is what folks need to know when configuring such devices.  Alternate port use can be used to get around rules you put in place and services like FTP in the old days would have used an FTP proxy and today that type of analysis on traffic to open the correct ports is called DPI.

Mostly for the IESG: I agree that this document does not update 6335. I agree that it is supplemental. And I agree that it's a BCP. So let's make it part of BCP165. This doesn't need a new BCP number. It's part of the same series.

1: A bit of clarification would be useful:

OLD
   Note that this document provides information to potential port
   number applicants that complements the IANA process described in
   BCP165 [RFC6335], but it does not update that document.
NEW
   Note that this document provides information to potential port number
   applicants that complements the IANA process described in BCP165
   [RFC6335], but it does not change any of the port number assignment
   procedures described therein.

I don't think you need to say anything about the "update" status.

2:

   In this document, the characters ">>" preceding an indented line(s)
   indicates a compliance requirement statement using the key words
   listed above. This convention aids reviewers in quickly identifying
   or finding the explicit compliance requirements of this RFC.

Generally, this sort of things simply produces eye-rolling in me and nothing more. 2119 keywords are not about "compliance", and so to claim above that you are using them "as described in RFC-2119" and then go on to include them in "compliance requirements" is bogus. However, most of these "compliance requirements" in the rest of the document are simply summary advice regarding what's going to be useful and what won't, so really what's in the ">>" is not a "compliance requirement", but rather an "Important Summary Note". I'd really prefer you call them that here. That said, one of them in 7.4 actually gave me pause:

   >> When simultaneously requesting both a secure and an insecure
   port, strong justification MUST be provided for the insecure port.
   Precedent (citing other protocols that use an insecure port) is not
   strong justification by itself.  A strong case for utility of the
   insecure service is REQUIRED for approval of the insecure port.

Here it sounds like you *are* imposing a requirement, and it sure sounds to me like you're specifying a registration procedure to be enforced by the Designated Expert or IANA, not giving a piece of advice to the registrant. If it wasn't for the last sentence in the above, I wouldn't have thought twice about it. So my two suggestions are:

- Change the text in section 2 to not call these "compliance requirements". If you don't like "Important Summary Note", choose something else.

- Change or delete the last sentence in the paragraph from 7.4. (I think delete is fine; it's repetitive anyway.)

7.4/7.5: I agree with Alissa's comments regarding the ">>" statements. Either re-word them to be about port assignment or ditch them.

I share Alissa's comments that the rationale for conservation is a bit shaky.  Clearly conservation is prudent, but it doesn't seem like there's a crisis here.

Section 3: The values in the "Binary" column are decimal, as indeed they are labelled in RFC 758.

Section 7.4: I agree with Stephen here.  Separate ports and STARTTLS are equivalent from a security/downgrade POV -- either you need to know to use the secure port, or you need to know to require STARTTLS to succeed.  The only difference is that STARTTLS adds latency if you're doing TLS. You can avoid that by starting secure (STOPTLS?), but in either case, there's a loser.  But ISTM that the document addresses this point sufficiently.

- I share the concern that this needs to be in-whack with
RFC6335 but sometimes overstates things, e.g. some of the
MUST NOTs in 7.7.  I'm fine that that's being discussed
already.

- The one-port/two-port thing: I don't think there's a real
seurity difference here in general, so that is not a basis on
which to prefer to discourage the registration of two ports,
nor is it a reason to prefer to do that. It is however, also
reasonable to want two ports, one e.g. using TLS and one not,
and it is equally reasonable to use STARTTLS.  Basically,
please move on, there's nothing to see here, find another
argument:-)

- I would like to see a statement that, in allocating a new
port for a "secure" variant of an existing protocol, the port
experts will consider actual deployment, even if it is the
case that some RFC says that one can do security stuff on the
currently assigned port. If we do not allocate such ports,
then we would be getting in the way of improving real
security, and that would be bad.  I'm not sure from the text
what the port experts do in such cases, but as that is not
addressed by the current document, the RFC that results won't
be a block on such allocations (where justified).

- 7.8, "easily resolved" to be the squatter's fault is not
true - in general people will I think consider the most
widely deployed use of a port to be in the right, and most
people won't even go look at the IANA registry. (Some will,
including no doubt the port experts.)