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

From: Lars Eggert <[email-masked]>
Date: Mon, 5 Oct 2009 11:22:54 +0300

Hi,

On 2009-9-29, at 17:10, [email-masked] wrote:
> I have followed up and studied the revised Port Number registry
> draft, draft-ietf-tsvwg-iana-ports-02.

thank you! We've been waiting for community feedback.

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

I'm sorry, but I see little argumentation in draft-gudmunsson on why a  
separate registry is preferable. Yes, the IANA rules for port numbers  
should be stricter than for service names, but that does *not* mean  
that a separate registry is needed - it just means that the rules  
should be different.

The main reason to have one registry is to make it easy for IANA and  
applicants to figure out which names are registered and which aren't.

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

Why do you think that? The unified registry contains service names,  
and is fully agnostic on what protocols those service names are used  
with.

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

Those labels are *already* registered, in the "keyword" column in the  
current IANA ports registry, and we don't know which ones are used and  
which ones aren't. Which is why we're keeping them defined as they  
currently are (modulo some renaming in very few cases.)

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

I don't follow. Yes, we want to leave APIs and databases unchanged,  
which is why we're keeping the current size restriction.

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

There is no danger of "imminent exhaustion" and if our draft leads you  
to believe that there is, we need to change it. System ports are  
somewhat scarce, but even there we have sufficient space left to last  
for years.

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

First, let me point out that Michelle is co-authoring the draft  
*because* we want to make sure that these rules are easier for IANA to  
apply than what currently exists.

Second, the purpose isn't to do an advertisement campaign that creates  
a strong momentum for service names - the purpose is to come up with  
clear and simple registry maintenance rules. If as a secondary effect  
that means that service names become more widely used, great, but  
that's not a primary driver for this draft.

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

The intent is that no expert review is involved for a service name  
allocation. Expert review only happens for a port number allocation,  
like it does currently. Under the new rules, a service name can be  
allocated FCFS without expert review.

(I just realized that -02 does actually not yet contain this - we need  
to submit -03.)

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

(ii) is *your* interpretation. In my reading, the SRV RR RFC makes it  
clear that any service name allocated in the ports registry should be  
usable with SRV RRs.

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

True. But that does *not* mean that we need two registries. It just  
means that we need two sets of procedures.

>    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

Correct. The intent is FCFS.

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

Randomization doesn't come into play here, because it's used for the  
source ports, whereas the registry is for destination ports.

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

No, this is MUCH to restrictive. We're NOT trying to make it harder to  
get a port number than it is currently. Port numbers remain the  
primary service identification method in the Internet. And yes, I  
agree that SRV RRs should be something that should be used more often.  
But making it harder to get port numbers only means more squatting.  
SRV RRs need to become attractive based on their own merits, and not  
because port number are hard to get.

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

FUD. IANA seems to like our proposal. For port number registrants,  
nothing changes much (except that the rules are now documented.) For  
service name registrants, nothing changes much.

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

See above, you repeated this point for the third time now.

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

Maybe yes, maybe no. In our scheme, it's possible, which is nice  
because it leaves the option.

I'm skipping your editorial comments for now.

Thanks,
Lars

---

From: Lars Eggert <[email-masked]>
Date: Mon, 5 Oct 2009 12:20:33 +0300

Hi,

On 2009-10-5, at 12:15, Fernando Gont wrote:
On Mon, Oct 5, 2009 at 5:22 AM, Lars Eggert <[email-masked]>  
wrote:
>> Randomization doesn't come into play here, because it's used for  
>> the source
>> ports, whereas the registry is for destination ports.
>
> Ephemeral ports (and randomization) do come into play.
...
> Therefore, these implementations of the
> TCP API should enforce a stricter requirement for the allocation of
> port numbers: port numbers that are in use by a TCP in the LISTEN or  
> CLOSED states should
> not be allowed for allocation as ephemeral ports.

Oh, I agree with excluding LISTEN/CLOSED.

But Alfred's point was that we shouldn't be *allocating* port numbers;  
presumably because he believes that the act of allocation removes them  
from the randomization pool - which isn't the case.

Lars

---

From: Fernando Gont <[email-masked]>
Date: Mon, 5 Oct 2009 06:15:00 -0300

On Mon, Oct 5, 2009 at 5:22 AM, Lars Eggert <[email-masked]> wrote:

> Randomization doesn't come into play here, because it's used for the source

See Section 10.2 of the d. ocument "Security Assessment of the
Transmission Control Protocol (TCP)" (available at:
http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf)
published by UK CPNI (or its IETF I-D counterpart
draft-gont-tcp-security).

This is an excerpt of the aforementioned document, for your convenience:

---- begin excerpt ----
10.2. Active opens and binding sockets

As discussed in Section 10.1, the “OPEN” command specified in Section
3.8 of RFC 793
[Postel, 1981c] can be used to perform active opens. In case of active
opens, the parameter
“local port” will contain a so-called “ephemeral port”. While the only
requirement for such an
ephemeral port is that the resulting connection-id is unique, port
numbers that are currently in
use by a TCP in the LISTEN state should not be allowed for use as
ephemeral ports. If this
rule is not complied, an attacker could potentially steal” an incoming
connection to a local
server application by issuing a connection request to the victim
client at roughly the same time
the client tries to connect to the victim server application. If the
SYN segment corresponding to
the attacker's connection request and the SYN segment corresponding to
the victim client
“cross each other in the network”, and provided the attacker is able
to know or guess the
ephemeral port used by the client, a TCP simultaneous open scenario
would take place, and
the incoming connection request sent by the client would be matched
with the attacker's
socket rather than with the victim server application's socket.
As already noted, in order for this attack to succeed, the attacker
should be able to guess or
know (in advance) the ephemeral port selected by the victim client,
and be able to know the
right moment to issue a connection request to the victim client. While
in many scenarios this
may prove to be a difficult task, some factors such as an inadequate
ephemeral port selection
policy at the victim client could make this attack feasible.
It should be noted that most applications based on popular
implementations of TCP API (such
as the Sockets API) perform “passive opens” in three steps. Firstly,
the application obtains a
file descriptor to be used for inter-process communication (e.g., by
issuing a socket() call).
Secondly, the application binds the file descriptor to a local TCP
port number (e.g., by issuing
a bind() call), thus creating a TCP in the fictional CLOSED state.
Thirdly, the aforementioned
TCP is put in the LISTEN state (e.g., by issuing a listen() call). As
a result, with such an
implementation of the TCP API, even if port numbers in use for TCPs in
the LISTEN state
were not allowed for use as ephemeral ports, there is a window of time
between the second
and the third steps in which an attacker could be allowed to select a
port number that would
be later used for listening to incoming connections. Therefore, these
implementations of the
TCP API should enforce a stricter requirement for the allocation of
port numbers: port
numbers that are in use by a TCP in the LISTEN or CLOSED states should
not be allowed for
allocation as ephemeral ports.
An implementation might choose to relax the aforementioned restriction
when the process or
system user requesting allocation of such a port number is the same
that the process or
system user controlling the TCP in the CLOSED or LISTEN states with
the same port number.
---- end excerpt ----

Kind regards,
-- 
Fernando Gont
e-mail: fernando at gont.com.ar || fgont at acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Fernando Gont <[email-masked]>
Date: Mon, 5 Oct 2009 06:53:47 -0300

Hello, Lars,

Comments inline....

> presumably because he believes that the act of allocation removes them from
> the randomization pool - which isn't the case.

(assuming you're talking about "allocating" in terms of the IANA's
administrative process)

Well, the act of IANA allocating ports (i.e., the administrative
process) doesn't preclude you from anything (obviously). However, one
would expect that if a port is allocated by IANA, it is because some
server app will use it. At that point, for the reasons stated in the
CPNI document, you should avoid using that port for the ephemeral
ports. Which means that the more ports you allocate, the fewer ports
you are assured you can use for the ephemeral ports without the
security implications described in Section 10.2 of the CPNI document.

(Whether taking the risk of being vulnerable to the aforementioned
issues is still acceptable (or not) for a particular
system/environment is another issue....)

Kind regards,
--
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 5 Oct 2009 19:47:48 +0200

On 5 okt 2009, at 11:53, Fernando Gont wrote:

> However, one
> ports.

First of all, server apps may use unallocated ports, too.

Second, how are TCP stacks supposed to know that a port has been  
allocated?

As far as I know, there are no issues with the normal practice of not  
caring about this.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 05 Oct 2009 18:48:53 -0300

> First of all, server apps may use unallocated ports, too.

If by "unallocated" you mean a port nor formally allocated by IANA, I
agree. To some extent, the usefulness of allocation is in documenting
its use, and in avoiding collisions.

> Second, how are TCP stacks supposed to know that a port has been allocated?

Not sure what you mean. Many implementations avoid using as ephemeral
ports those port numbers that are used for specific services.

I wrote the patch to expand the ephemeral port number range in FreeBSD,
and the reason for which FreeBSD's ephemeral port range ended up being
10000-65535 (rather than 1024-65535) was to avoid using those port
numbers used for X, http-proxy, etc. (This was a quick hack... a more
clean approach is described in draft-ietf-tsvwg-port-randomization). --
OpenBSD does implement that approach.

> As far as I know, there are no issues with the normal practice of not

Normal practice does care about this... that's probably why there are no
issues ;-)

Kind regards,

---

From: Alfred Hönes <[email-masked]>
Date: Sat, 17 Oct 2009 00:38:53 +0200 (MESZ)

Please find inline below detailed responses to the single feedback
received so far for my review of draft-ietf-tsvwg-iana-ports-02,
which contained a detailed critique of the incorporation of
a registry for DNS SRV "service labels" (for dynamic service
discovery), into the Port Number registry (for static port number
assignments), as suggested by this draft.

For those looking for an 'executive summary' - here it is:

draft-gudmundsson-dns-srv-iana-registry-03 has proposed a distinct
registry for DNS SRV Service Prefixes, the need for which
apparently had been overlooked in RFC 2782 (the specification of
the DNS SRV resource records).  That registry is tailored for the
needs of applications/services making use of any "transport" or
"substrate" protocols (like HTTP) and use domain/server specific
port numbers assigned under local authority (or dynamically) for
the underlying transport, and which utilize DNS SRV based dynamic
service discovery by the clients, or the SRV based "DNS database"
of the Dynamic Delegation Discovery System (DDDS).
That proposal is based on feedback and requests from application
protocol designers which have a broader view of underlying protocols
for their applications than the narrow "IETF Transport Protocol with
an IANA assigned Protocol number" focus of the Port Numbers registry,
which otherwise fulfills the needs for applications/services using
the IETF Transport protocols (TCP, UDP, SCTP, DCCP) and fixed,
globally uniwu, IANA-assigned server port numbers.
draft-ietf-tsvwg-iana-ports has been extended in the -02 version
to reclaim authority for the registration of many Service labels
in the Port Numbers registry, which is incompatibel with the
design of the former proposal and the differing requirements.

At  Mon, 5 Oct 2009 11:22:54 +0300, Lars Eggert wrote:

> In-Reply-To: <[email-masked]>
> Message-Id: <[email-masked]>
> Subject: Re: [tsvwg] draft-ietf-tsvwg-iana-ports-02
>
> Hi,
>

I apologize for the delay in responding, but in part I expected
more discussion -- which didn't happen so far -- and wanted to sum
up subsequently.

> that a separate registry is needed - it just means that the rules

Well, most part of draft-gudmunsson-dns-srv-iana-registry-02 have
been written almost one year ago. It was out of reach of my
influence that the -02 did not happen to get posted before, or
at least around IETF 73, but only before IETF 75.
Those days it could not be envisioned that draft-tsvwg-iana-ports
would be expanded in the way it has been done now.
Our -03 is only a fix-up of items that should have been fixed for
the -02, but couldn't because I've been offline for a substantial
time period.

If you prefer, we can include a lot of rationale in the next
revision of our draft, but, because you didn't either explain the
reasons to expand the scope of your draft therein as well, we
preferred to carry out the discussion 'out-of-band' of our draft.

> applicants to figure out which names are registered and which aren't.

I don't see a major hurdle there. `grep`ing 2 files isn't more
complicated than `grep`ing a single.

But would a protocol designers specifying service discovery for
their application/service understand that they had to register
their service prefix in the Port Number registry, although they
do not want to apply for an assigned port at all?

We have provisioned a leightweight procedure to ensure that
collisions between the traditional, length-restricted service
names and (potentially longer) SRV service labels will not occur.

> and is fully agnostic on what protocols those service names are used

That's one part of the problem.

The Port Number registry deals with transport protocols that have
port numbers as demultiplexing selectors, and only with these.
In a similar way as IPSEC had (and still has) to discover that
other kinds of selectors exist in other protocols and need to be
supported, existing IETF standards have created a variety of
SRV service prefixes that are not bound to the four transport
protocols supported by the Port Number registry (TCP, UDP[-Lite],
DCCP, and SCTP), for instance:

     _pkixrep._ldap

        _pres._sip

        _mip6._ipv6

The Protocol labels are significant there.
You'll never have things like  _telnet._sip !
But there are:

      _pkirep._ocsp

        _pres._xmpp

The essential point is that service discovery is always bound to
specific service/protocol combinations, and only those that are
actually specified should be listed in a service prefix registry.
It makes no sense from an application PoV to be "fully agnostic"
on what protocol is going to be used with a particular service.

> currently are (modulo some renaming in very few cases.)

The renaming effort has our full support.  It does not touch
in any way the model of the Service Prefix registry because the
initial content of that registry (as picked up by harvesting RFCs)
is already 'clean' in their namespace usage and entirely unaffected
by this step.

However, most service _names_ currently registered in the Port
Numbers registry have limited use.  Those names (originating from
the /etc/services file on POSIX systems) actually in somehow
widespread used are those for the most well-known services, which
traditionally have been bound to registered port numbers and will
-- in their majority -- not have service discovery specified or
in use, or have it being specified and used in the future.

The majority of the service names are registered with ports for
applications with limited deployment, and these service names
most likely will not be listed in the majority of /etc/services
files in the wild, because their presence would only slow down
the lookup -- only locally deployed services are getting added
in practice, and only when these applications are indeed bound to
fixed (configured) port numbers and their users are not expected
to perform dynamic service discovery, e.g. via DNS SRV RRs.

As you can see from our draft, the SRV service prefix registry
is designed for a peaceful coexistence with the Port Numbers
registry, and is expected to grow up becoming mostly complementary
to it; registrations are based on specifications of service
discovery for an application/service, not on the specification
of a 'basic', perhaps transport-agnostic, application protocol,
which in turn would be the likely reference to be entered into
the Port Number registry in case a dedicated port number were
needed.

Existing (and future) registrations in the Port Number registry
are encouraged to be amended by a registration in the Service
Prefix registry, if and when service discovery is specified for
that application/service, but it is expected (based on feedback
from vendors) that future Service Label registrations will more
and more not be accompanied by Port Number assignment requests.

You share the expectation of, and in fact also want to encourage,
more widespread use of service discovery in the future.  According
to the principle of least surprise, application designers should
not be confused by having to register in a Port Number registry
in such case, even when it is renamed in "Port Numbers and ...".

> which is why we're keeping the current size restriction.

The main characteristic of (dynamic) service discovery is that it
takes into account the destination (domain) as an input parameter
as well.
In contrast, the "service-to-port resolution" using service names
is destination-independent, which is reflected in the traditional
APIs for "service [name] to port number" resolution.

High level APIs for service discovery are not yet standardized,
AFAICT, but their interfaces will be different from those for
the simple name-to-port resolution.  The design of the Service
Prefix registry accommodates the desire of application designers
to use verbose, in part hierarchically structured service labels,
which can quickly outgrow the traditional limits.

> somewhat scarce, but even there we have sufficient space left to last

Admittedly, the time scale can vary, but the available unassigned
port number namesspace is decreasing steadily.  Since reclaiming
procedures are new and still will have to prove their efficacy,
from a mathematical point of view, it's almost inevitable that
the remaining namespace will become scarce.  I did not attempt
to forecast when, but absent incentives for not using assigned
port numbers for new applications/services, this will inevitably
happen within the expected lifetime of the current Internet
technology.  I have archived a few snapshots of the port-numbers
file over time, and a rough extrapolation of their line counts
indicates that this will perhaps take much less time.

> *because* we want to make sure that these rules are easier for IANA
> to apply than what currently exists.

Admitted and appreciated.

> that's not a primary driver for this draft.

But then it seems illogical to reclaim authority over the entire
namespace needed for service discovery as well.

Keeping both registries visibly separated, but interrelated
by the collision-avoidance rule seems more registrant-friendly
and even better manageable for IANA.

> (I just realized that -02 does actually not yet contain this - we need

You will admit that I would have had difficulties reasoning about a
not-yet-written draft version.   :-)

> clear that any service name allocated in the ports registry should be

I hope you admit that we manage the interpretation of our own
targets.  :-)

'Usable' does not mean that use is specified, and experience has
shown that this has to be done carefully.

Anyway, a lot of RFCs have assumed the existence of a distinct
registry for Service Prefixes and tried to register there explicitly.

Our proposed Service Prefix registry for that RFC does not preclude
basing Service Labels on service names from the Port Number registry;
actually, it *reserves* all service names listed there, with and
without a prepended underscore character, as candidates for Service
Label registrations with some Protocol Labels, for just that service
that originally obtained the related assigned port number.

The gap to be closed by registrants is the documentation for the
use of service discovery with that application/service, and it's
*that* specification that will be listed in the Service Prefix
registry entries.

Currently there are almost a dozen I-Ds on the table (anywhere
between initial individual draft and RFC Editor queue) that discuss
the use of service discovery via SRV RRs for specific applications /
services, and this is really needed to obtain interoperable
functionality, in particular when NAPTR RRs and/or other mechanisms
are used jointly with the SRV RRs.  In particular there's a need for
guidance from an operational and management PoV.  E.g., DNS Zone
administrators will need to be convinced of the utility of the new
RRs they are asked to host, and they will want to be presented
with an analysis of the expected operational impact.  Blindly
putting lots of SRV RRs in various zones does not make sense.

>
>>    Due to the vastly different size of the available namespace,

But having entries with different syntax, different restrictions,
and so much different procedures and IANA policy in a single registry
is very unusual (at best), and most likely simply confusing.

> Correct. The intent is FCFS.

As above.  I couldn't comment on unpublished intent.

> source ports, whereas the registry is for destination ports.

I'll exclude this topic; it as been discussed on the list already.

> No, this is MUCH to restrictive. We're NOT trying to make it harder
> to get a port number than it is currently. Port numbers remain the

This point of view apparently is not shared by all.

For instance, IP address sharing as a component of a v6 transition
path, is incompatible with such strategy.

Since this is not the main point here, I simply would like to point
out that apparently many folks would appreciate a decided pressure
to shift that fixed-port-number-centric paradigm and would prefer
to thus reduce the semantical overloading of port numbers, serving
as (de-)multiplexing selectors and questionable service identifiers
at once (there's no Internet police to enforce port number use),
in order to reduce, in the long term, their role to a single purpose,
namely serving as transport (de-)multiplexing selectors, which is their
sole role already on the client side of client-server applications.

> agree that SRV RRs should be something that should be used more often.

+1

> But making it harder to get port numbers only means more squatting.

It should serve as an incentive for application protocol designers
to spend more thoughts on the intrinsic support of service discovery,
to ensure interoperable implementations and manageable deployment
of their appplications in the presence of emerging obstacles to
fixed port number usage.  This strategy should actually in fact
off-load IANA and Review Experts.

> because port number are hard to get.

Slope (and the resulting moment) is the result of the difference
in altitude between two points.

> FUD. IANA seems to like our proposal. For port number registrants,

Well, I assume that the requirements a Service Prefix registry
needs to fulfill have not been explained and discussed before in
depth, and the deficiencies of the model had not been exposed yet.
So I hope that after looking at the arguments, a re-evaluation will
be granted.

> nothing changes much (except that the rules are now documented.)

We never intended to interfere with the details.

> For service name registrants, nothing changes much.

No.  Many kinds of Service Prefixes could not be registered with
that registry as laid out in tsvwg-iana-ports-02, as detailed above.
(Where to enter hypothetical prefixes like
		  _xzzzyx._https ,
		  _foobar._scvp ,
	    and   _abc123._xmpp  ? )

The most important information - actual support of service discovery
by the application, and where it is documented, would be lacking.

Having columns in the single table only to be filled in for certain
kinds of registrations and other columns to be filled in only by
other registrations isn't a clear and simple model, and makes
processing rules unnecessarily complicated.

> See above, you repeated this point for the third time now.

The emphasis has been different aspects:
-  IANA assignment of code points (port#) vs.
   mere registration of Service Labels / Prefixes;
-  mandatory service name (for name-to-port resolution) does not
   imply application support of service discovery (both client-side
   and from a provisioning PoV on the server side);
-  management aspects of IANA procedures;
-  presentation of the registries;
-  clarity for applicants;

> because it leaves the option.

The collision avoidance procedures we propose aim at ensuring
that this rare case remains an option as well.

> I'm skipping your editorial comments for now.

Granted.

> Lars

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| 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]                     |
+------------------------+--------------------------------------------+

---

From: Joe Touch <[email-masked]>
Date: Sun, 18 Oct 2009 18:13:25 -0700

Fernando Gont wrote:
...
>...Which means that the more ports you allocate, the fewer ports

The ephemeral port range is not affected by allocations in the
non-ephemeral range. The issue above would occur only if the current
non-ephemeral range were exhausted and we moved the boundary between the
two to allow for more allocations.

As Lars noted, we're in no danger of running out of ports. I presented a
summary in TSVWG in IETF 73. We've been linear in allocations/year
(around 400) from 2001 through 2008 (when I made that chart). At that
rate, we have at least 85 years to go...

49152 - 1024 (omit all the system ports) - 5500 (remove allocations
through 2008, rounded up a hundred) / 500/yr (20% more than we have been
for the last 8) = 85 years.

Joe

---

From: Joe Touch <[email-masked]>
Date: Sun, 18 Oct 2009 18:15:21 -0700

Fernando Gont wrote:
...
> OpenBSD does implement that approach.

That technique doesn't expand the ephemeral range. It uses the reserved
range as ephemeral, which will cause problems when ports in that range
are allocated and you're already running a service on it.

It's not clean at all, and should be avoided, IMO.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Mon, 19 Oct 2009 05:12:37 -0200

Joe Touch wrote:

> range as ephemeral, 

Did you mean "registered"?

> which will cause problems when ports in that range

Is this one of those "let's ignore the facts" speeches?

The very same Windows box you're using probably uses the range 1024-4999
for the ephemeral ports.

See the survey in the port-randomization I-D.

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Mon, 19 Oct 2009 01:58:28 -0700

> Did you mean "registered"?

Yes.

> Is this one of those "let's ignore the facts" speeches?

It's "let's fix the end with the bug, rather than create a new bug to be
dealt with later" speech.

> The very same Windows box you're using probably uses the range 1024-4999

That would be a bug.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Mon, 19 Oct 2009 08:26:26 -0200

> dealt with later" speech.

I'd argue that for client systems, reducing the port number space used
for outgoing connections (i.e. ~64K vs ~15K) is more likely to introduce
problems.

Also, in retrospective, with the "registered ports" thing you're wasting
most of the port number space when you will probably use... what? a
maximum of 10 or 20 ports of those 50K ports?

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Mon, 19 Oct 2009 03:33:45 -0700

> for outgoing connections (i.e. ~64K vs ~15K) is more likely to introduce

It'd be useful to consider whether there are actually 15K connections
and thus a real problem, or whether the hosts are incompletely
implementing port reuse checks that prevent a port from being used for
different IP addresses simultaneously. I.e., what's the greater impact
1/4 of the total space, or false positives due to implementation issues?

> maximum of 10 or 20 ports of those 50K ports?

And only 6,000 of those 50K are even assigned. Again, though, making the
space even 4x larger has only a 4x impact on current issues - that's not
all that much, IMO.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Mon, 19 Oct 2009 08:53:03 -0200

Joe Touch wrote:

> and thus a real problem, 

file sharing (p2p) applications tend to create lots of connections.
Although I wouldn't go as far as 15K (at least for *my* client systems).
When it comes to e.g., a busy web-proxy server and similar systems, I
guess the number of ongoing connections increases quite a bit.

> or whether the hosts are incompletely
> different IP addresses simultaneously. 

Unfortunately, you need to do this. See the API section in the CPNI TCP
document (i.e., connection stealing).

If we had socket(),bind(), and listen() combined in a single system call
(and that was the only way to do things), then I'd agree that we could
implement the checks you refer to.

> And only 6,000 of those 50K are even assigned. 

Had not check the number of currently registered ports. -- interesting.

> Again, though, making the

Not all that much... but certainly better than 1x.

---

From: Joe Touch <[email-masked]>
Date: Mon, 19 Oct 2009 04:04:12 -0700

> guess the number of ongoing connections increases quite a bit.

If these are persistent connections between two IP addresses for the
same service, it begs the question of whether the connections should be
persistent.

> implement the checks you refer to.

I'm talking about a system that declares port 49999 "in use" for all IP
addresses when it's in use for one, just to save the space and/or
computation of keeping more detailed state. I wasn't referring to the
checks that are required as a result of the lack of a single OS call to
setup a connection.

> Not all that much... but certainly better than 1x.

A X increase in BW results in an X^2 increase in vulnerability, as
explained in RFC4953. A X increase in ports would result in an X
increase in resistance, which isn't going to keep up. I.e., this is a
small and fixed one-time increase that simply won't have enough of an
impact to justify changes in how we assign or use ports. There are other
good reasons (allowing endpoints to determine port use, removing the
need for an index, etc.), but not this.

Joe

---

From: Eliot Lear <[email-masked]>
Date: Mon, 19 Oct 2009 17:29:35 +0200

I'm confused.  Outbound and inbound port numbers are complete separate 
name spaces, aren't they?

---

From: Joe Touch <[email-masked]>
Date: Mon, 19 Oct 2009 12:39:06 -0700

> name spaces, aren't they?

They should be, but in implementations they often aren't. E.g., you bind
to 80 to listen, and now you cannot use 80 as a source port for outbound.

Further, some (IMO, poor) implementations use one space to count which
dynamic ports are in use.

So they should be separate, but they might not be...

Joe