Subject: [tsvwg] draft-ietf-tsvwg-iana-ports-02

From: Alfred Hönes <[email-masked]>
Date: Tue, 29 Sep 2009 16:10:07 +0200 (MESZ)

Hello,
I have followed up and studied the revised Port Number registry
draft, draft-ietf-tsvwg-iana-ports-02.

Lars has solicited on the TSVWG list reviews of that draft, and
I have quite a couple of comments.
Because of the extended scope of the topic, this note is also
circulated to APPS-DISCUSS.

The bulk of items below is divided into part (A) discussing
substantial general issues and part (B) dedicated to (more or
less) editorial issues found in the draft.  Readers only
interested in the points perhaps needing discussion can safely
stop reading after the first part.

(A)  General issues

(A.1)  Intended expansion of the Port# registry to Service Names

The -02 draft revision has proposed to expand the Port Number
registry to also cover "Service Names" -- independent of the
assignment of port numbers to applications/services.

There are lots of reasons to not do that in the proposed form.

After discussions with driving forces from the Applications Area,
draft-gudmundsson-dns-srv-iana-registry-03.txt has reinforced and
reconciled the proposal for a dedicated Service Prefix registry.
Please refer to that draft for distinguishing details.

For terminological clarity, the sketch of arguments below uses
the terminology established in the context of DNS and the SRV RR
specification (RFC 2782), as used in that draft:
o  Service label   - the 1st label in the owner name of a SRV RR
                     (up to 63 characters, optionally including
                      a leading underscore character),
o  Protocol label  - the 2nd label in the owner name of a SRV RR
                     (including a leading underscore character),
o  Service Prefix  - the combination of the above (used with SRV RRs),
whereas the term "Service Name" is used as in the iana-ports draft
for the existing designation of a service in the port number registry
(not including a leading underscore character).

Here are the primary aspects that come to mind regarding the nature
and implementation of registration services for Port Numbers and
Service Prefixes:

(a) Since there is an established and IETF-documented practice
    for the use of "overlay" / "substrate" SRV Protocol labels,
    Service Labels making use of these should be registered
    in a similar manner as others containing proper "transport"
    Protocols, under the same procedural rules.  The database
    proposed in draft-tsvwg-iana-ports-02 is neither prepared to,
    nor suitable for, also accepting the registration of such
    Service Prefixes not related to IETF transport protocols.

    Reclaiming the registration authority for 'pure' transport
    protocol labels (currently: _tcp, _udp, _dccp, and _sctp) by
    the Port Numbers registry would unnecessarily and confusingly
    split the SRV service label and prefix namespaces into two
    parts, one covered by the Port Numbers registry, one by
    another registry; that would make service label registration
    and namespace management ugly and confusing.

(b) Most legacy applications with registered port numbers are
    not prepared to use SRV RRs (yet); it does not make sense
    to proactively register myriads of labels without having
    any documentation on the use of service discovery for that
    service, and without consent and knowledge of the original
    applicants for port number assignment.

    For fulfilling its purpose, a Service Prefix registry should
    only contain entries for applications and services indeed
    intended and prepared to make use of service discovery.

(c) For compatibility with existing databases and APIs,
    draft-tsvwg-iana-ports-02 essentially maintains the
    'classical' size restrictions for Service Names.

    APIs for (dynamic) service discovery will easily admit the use
    of the common 63-character size for DNS labels (as established
    by RFCs 1034/1035), for SRV Service labels as well.

    Applications making use of (dynamic) service discovery based
    on DNS SRV have to be written to use such API, and if existing
    applications previously bound to an assigned port number are
    being upgraded to use service discovery, they need to be
    modified to use such API anyway.

    Therefore, it makes sense to leave existing databases and APIs
    for Service-Name-to-Port-Number lookup unchanged.

(d) The imminent exhaustion of the port number space is recognized as
    a reason to encourage the migration to service discovery for new
    applications; draft-tsvwg-iana-ports-02 also acknowledges that.

    However, we believe that the procedures envisioned in that draft
    are much too heavy-weight -- and too burdensome for IANA as
    well -- for exerting a strong momentum towards service labels.

    The compound database needed for draft-tsvwg-iana-ports-02 and
    the Expert Review process inadequately address the needs -- of
    both the prospective applicants and the registry maintainers.

(e) The Port Numbers registry and the SRV Service Prefix registry
    serve very different purposes:
    i)  registration of and lookup of assigned port numbers
    ii) registration of Service Prefixes actually defined for
        service discovery.

    Due to the vastly different sice of the available namespace,
    both registries need different assignment/registration policies.

    For the Service Prefixes (with the exception of the establishment
    of new Protocol Labels), an extremely lightweight procedure is
    needed where the role of the IANA is confined to checking
    uniqueness (avoiding registry-internal collisions and collisions
    of new Service Labels with Service Names already registered in
    the Port Numbers registry for other services, as specified in
    detail in draft-gudmundsson-dns-srv-iana-registry-03) and
    ensuring precedence (by first-come-first-served principle).
    Basically: No *assignment* function is needed in this registry,
    only *registration*.
    The Service Label registry is expected to grow rapidly.

    The Port Number registry is heavily constrained by the 16-bit
    namespace available, with the additional pressure resulting
    from the security critical need for client port randomization
    to only assign as few as possible additional port numbers.
    It is the basic nature of such restricted namespace that the
    IANA registry for it needs to be under *assignment* paradigm.
    The port number registry should be regarded as "almost closed"
    (reserved for cases where service discovery is impossible),
    and it needs rigid and tight management and strict IANA policy.

    Merging such different registries appears as a nightmare for IANA
    and prospective applicants, and all 'consumers' of the registry.
    The complicated amalgamated specification needed for the IANA
    procedures for such registry is contrary to the principles of
    clarity and simplicity.

(f) The management of a narrow/scarce namespace (port numbers)
    should not be conflated with the management of an ample
    namespace; hence the need to have two independent registries,
    with existing service names in the Port Numbers registry
    implicitly reserved for use as Service Labels as well
    (for all Protocols) for the same application.

(g) New applications/services initially registering a SRV Service
    Prefix but not applying for the assignment of a dedicated
    port number are very unlikely to do that later.

    For sanity, the Port Numbers registry should not accept any
    Service Name equivalent to a Service Label already registered
    for a different application/service in the SRV Service Prefix
    registry.

(A.2)  Section 1, 2nd para -- transport session identifiers

The draft says:

            [...], and the combination of source and destination port
   numbers together with the IP addresses of the communicating end
   systems uniquely identifies a session of a given transport protocol.

Just a few weeks ago, the CALIPSO RFC has been published (RFC 5570),
which contains an updating correction for RFC 793 with regard to
the full identification tuple for transport sessions.
Although that RFC has restricted scope, it might be worth noting
that the transport session identifier generally has an additional
component, in order to allow compartmented MLS systems to conform
with preexisting security standards.

(A.3)  Terminological precision: "namespace" vs. "registry"

The draft repeatedly confuses "namespace" and "registry".
The scarce resource is the (16-bit) port number space, not the
Registry (cycles of the IANA or filespace in their data bases).

Some related details and suggested corrections are included in
part (B) below.

(A.4)  Roles of port numbers: confusion and lack of precision

The draft does not make the proper distinction between the various
categories of ports:

a)  per connection: client (ephemeral) vs. server / service port
    (exception: peer-to-peer applications using the same port number
     on both ends of a transport session)

b)  per packet:     source port vs. destination port

Since the draft addresses the registry of ports assigned to services,
it is inappropriate and confusing to use a term from category b) in
 defining the scope of the draft.

Hence, the 3rd para of Section 1 needs to be adjusted:

   Hosts running services, hosts accessing services on other hosts, and
   intermediate devices (such as firewalls and NATs) that restrict
   services need to agree on which service corresponds to a particular
|  destination port.  [...]
---^^^^^^^^^^^
   Hosts running services, hosts accessing services on other hosts, and
   intermediate devices (such as firewalls and NATs) that restrict
   services need to agree on which service corresponds to a particular
|  server port.  [...]
   ^^^^^^

Similarly, in the 5th para the designation of the mentioned port
numbers as a service port is a necessary clarification, needed to
avoid inappropriately streching the applicability of the draft to
client ports as well:

   Designers of applications and application-level protocols may apply
   to IANA for an assigned port number and service name for a specific
   application, and may - after successful registration - assume that no
|  other application will use that port number and service name for its
   communication sessions.  [...]
---
   Designers of applications and application-level protocols may apply
   to IANA for an assigned port number and service name for a specific
   application, and may - after successful registration - assume that no
|  other application will use that server port number and service name
                                  ^^^^^^^^
   for its communication sessions.  [...]

A similar clarification is needed in Section 4, 1st para, and
in other places; for examples please see (B.4) and (B.7) below!

(A.5)  Reminder on ambiguity of port numbers observed in the wild

Deliberate abuse of the simplified related to the statement in
Section 1 quoted in (A.2) by policy setting entities is a common
source of trouble for clients that do not provide a particular
service with an assigned unique port number and hence should be
free to use that port number as an ephemeral (client) port number
for any application.

Only stateful filtering of connection oriented transport sessions
(e.g. TCP) or perhaps -- with restricted probability of success --
deep inspection of connectionless (e.g. UDP) packets is able to
determine the actual role of the communicating peers and hence the
significance of port numbers occurring in packets subject to
filtering decisions, for the purpose of identifying applications /
services.

I strongly recommend that this issue be discussed in the Security
considerations as well.

(A.6)  Registration template in Section 6.1

It does not make much sense to define differing policies for the
two port number ranges and _not_ providing the applicant with a
possibility to request a port number from the particular range
desired.

I strongly suggest to make the (still missing) range designation
and the kind of the application (new / update) the initial items
in the registration template specified in Section 6.1.
Alternatively, the 'wildcard' "ANY" mentioned in the 4th bullet of
Section 6.1 should be re-specified to be either "ANY WELL KNOWN"
or "ANAY REGISTERED" (or similar).

Further, the bullets in 6.1 are inconsistent regarding the
admittance of an application for multiple ports.
Most bullets talk about "port" in singular (only), but the
4th bullet ( labelled "Port Number:" (!) ) out of the blue
talks about "port number(s)" and "port numbers".
Most likely, singular "port number" should be used uniformly.

(B)  (Mostly) Editorials

(B.1)  Abstract

Please use the common spelling of RFC designations within prose text,
with a space character between "RFC" and the RFC number.
In the 2nd para of the Abstract:
     s/RFC2780/RFC 2780/
     s/RFC4340/RFC 4340/

(B.2)  Section 1, 4th para -- singular/plural mismatch, clarification

Please correct:

   Applications either use numeric port numbers directly, look up port
   numbers based on service names via system calls such as
   getservbyname() on UNIX, or - more recently - use service names to
|  look up a service resource records (SRV RRs) [RFC2782] via the Domain
           ^                        ^?
   Name System (DNS) [RFC1034] in a variety of ways [RFC1078]
   [I-D.cheshire-dnsext-dns-sd][I-D.cheshire-dnsext-multicastdns] to
|  obtain the port number of a given service.
---                                         ^
   Applications either use numeric port numbers directly, look up port
   numbers based on service names via system calls such as
   getservbyname() on UNIX, or - more recently - use service names to
|  look up service resource records (SRV RRs) [RFC2782] via the Domain
   Name System (DNS) [RFC1034] in a variety of ways [RFC1078]
   [I-D.cheshire-dnsext-dns-sd] [I-D.cheshire-dnsext-multicastdns] to
|  obtain the port number of a given service instance.
                                            ^^^^^^^^^

The distinction between a "service" and a "service instance" (or
"instance of a service", if you prefer) is important: the service
discovery and lookup via SRV allows to host multiple logical
instances of the same service on a particular system, using
different server port numbers.

Note:
  Wouldn't it be appropriate to at least mention (beyond the
  cited I-Ds) the DDDS already standardized in the IETF, of which
  various flavors are in widespread use (e.g., ENUM) ?

(B.3)  Section 3, last para -- missing article

Please adjust:

                 [...].  These include procedures to de-register a port
   number that is no longer in use, to re-use a port number allocated
   for one application that is no longer in use for another application,
|  and procedure by which IANA can unilaterally revoke a prior port
      ^
   number registration.  Section 6 discusses the specifics of these
   procedures.
---
                 [...].  These include procedures to de-register a port
   number that is no longer in use, to re-use a port number allocated
   for one application that is no longer in use for another application,
|  and a procedure by which IANA can unilaterally revoke a prior port
      ^^^
   number registration.  Section 6 discusses the specifics of these
   procedures.

(B.4)  Section 4, 1st para

The draft inappropriately talks about "namespaces for ... registries"
and once more omits the important confinement on _server_ ports.
Please adjust:

   TCP, UDP (and UDP-Lite), SCTP and DCCP use 16-bit namespaces for
|  their port number registries.  The port registries for all these
                    ^^^^^^^^^^^^      ^^^^
   transport protocols are subdivided into three ranges of numbers, and
   Section 5.2 describes the IANA procedures for each range in detail:
---
   TCP, UDP (and UDP-Lite), SCTP and DCCP use 16-bit namespaces for
   their port numbers.  The server port registries for all these
                     ^     ^^^^^^^^^^^^
   transport protocols are subdivided into three ranges of numbers, and
   Section 5.2 describes the IANA procedures for each range in detail:

(B.5)  Section 5 -- punctuation

The bullets in Section 5 are all built of fulll sentences.

Hence, please supply trailing periods (5 instances).

(B.6)  Section 5.1, 4th text para -- word omission

In the 4th text paragraph (below the first group of bullets), the
word "by" should be inserted for clarity (this kind of modification
has frequently been performed by the RFC Editor in the recent past):

   [...]
   Applications and protocols are also expected to be able to
   efficiently use a single allocated port for multiple sessions, either
|  by demultiplexing multiple streams within one port, or using the
   allocated port to coordinate using dynamic ports for subsequent
   exchanges (e.g., in the spirit of FTP [RFC0959]).
---
   Applications and protocols are also expected to be able to
   efficiently use a single allocated port for multiple sessions, either
|  by demultiplexing multiple streams within one port, or by using the
                                                         ^^^^
   allocated port to coordinate using dynamic ports for subsequent
   exchanges (e.g., in the spirit of FTP [RFC0959]).

(B.7)  Section 5.2, 2nd bullet -- clarifications

Here again, (A.2) and (A.3) apply.  Please correct:

   o  Ports in the Registered Ports range (1024-49151) are available for
      registration through IANA, and MAY be used as service identifiers
|     upon successful registration.  Because registering a port number
      for a specific application consumes a fraction of the shared
|     resource that is the port number registry, IANA will require the
                                       ^^^^^^^^
      requester to document the intended use of the port number.  [...]
---
   o  Ports in the Registered Ports range (1024-49151) are available for
      registration through IANA, and MAY be used as service identifiers
|     upon successful registration.  Because registering a server port
                                                          ^^^^^^^^
      number for a specific application consumes a fraction of the
|     shared resource that is the port number space, IANA will require
                                              ^^^^^
      the requester to document the intended use of the port number.
      [...]

(B.8)  Section 5.3 -- multiple issues

As in (B.5) above, please supply trailing periods for the bullets
(3 instances).

In the last sentence of the 2nd text paragraph, the draft says:

                                                        [...].  An
|  application MUST NOT assume that it can use a port number assigned to
   it for use with one transport protocol with another transport
|  protocol without asking IANA to convert the reservation into an
                    ^^^^^^
   assignment.

Apparently, only "asking IANA" is not sufficient; the request MUST
have been accepted and applied to the registry before the usage can
be extended!  Furthermore, the "use" to be allowed is only the use
as a server port.   So please rephrase, for instance:

                                                        [...].  An
|  application MUST NOT assume that it can use a server port number
                                                ^^^^^^^
   assigned to it for use with one transport protocol with another
|  transport protocol without having caused IANA to convert the
                              ^^^^^^^^^^^^^
   reservation into an assignment.

(B.9)  Section 6.1, 6th bullet -- singular/plural mismatch

Please correct:

   o  Service Code: A desired unique service code for the service
      associated with the registration request.  Service codes are
      specific to the DCCP protocol [I-D.ietf-dccp-serv-codes]; the
      request MUST include a desired service code when the registration
|     requests includes DCCP as a transport protocol, and MUST NOT
             ^
      include one otherwise.
---
   o  Service Code: A desired unique service code for the service
      associated with the registration request.  Service codes are
      specific to the DCCP protocol [I-D.ietf-dccp-serv-codes]; the
      request MUST include a desired service code when the registration
|     request includes DCCP as a transport protocol, and MUST NOT
      include one otherwise.

(B.10)  Section 8.1, 2nd para

The draft says:

   Unfortunately, the current port number registry [REGISTRY] contains a
   few assigned service names that do not conform to the new naming
   rules.  In all cases, this is because they contain illegal characters
|  such as asterisks, dots, plusses, slashes, or underscores.  (All
          ^^^^^^^^^^^
   current service names conform to the length requirement of 15
   characters or less.)

However, the table at the end of the section does not contain evidence
that asterisks have been used in the past; there is no instance of a
service name containing an asterisk in the table.
Therefore, I suggest to drop "asterisks," from the text:

   Unfortunately, the current port number registry [REGISTRY] contains a
   few assigned service names that do not conform to the new naming
   rules.  In all cases, this is because they contain illegal characters
|  such as dots, plusses, slashes, or underscores.  (All current service
   names conform to the length requirement of 15 characters or less.)

(B.11)  Section 8.2, 1st para -- word omission

Please insert another "for" (or perhaps better: "with") in the 1st
sentence:

   Two Well Known ports, 1021 and 1022, have been reserved for
|  experimentation UDP and TCP [RFC4727].  [...]
---               ^
   Two Well Known ports, 1021 and 1022, have been reserved for
|  experimentation with UDP and TCP [RFC4727].  [...]
                  ^^^^^^

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+