headers
Lars Eggert | 5 Oct 10:22
Picon
Gravatar

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

Hi,

On 2009-9-29, at 17:10, ah <at> tr-sys.de 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.
(Continue reading)

Permalink | Reply |
headers
Fernando Gont | 5 Oct 11:15
Picon
Favicon

Re: draft-ietf-tsvwg-iana-ports-02

On Mon, Oct 5, 2009 at 5:22 AM, Lars Eggert <lars.eggert <at> nokia.com> wrote:

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

Ephemeral ports (and randomization) do come into play.

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
(Continue reading)

Permalink | Reply |
headers
Lars Eggert | 5 Oct 11:20
Picon
Gravatar

Re: draft-ietf-tsvwg-iana-ports-02

Hi,

On 2009-10-5, at 12:15, Fernando Gont wrote:
On Mon, Oct 5, 2009 at 5:22 AM, Lars Eggert <lars.eggert <at> nokia.com>  
wrote:
>
>>>   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.
>
> 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
(Continue reading)

Permalink | Reply |
headers
Fernando Gont | 5 Oct 11:53
Picon
Favicon

Re: draft-ietf-tsvwg-iana-ports-02

Hello, Lars,

Comments inline....

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

(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
(Continue reading)

Permalink | Reply |
headers
Iljitsch van Beijnum | 5 Oct 19:47
Favicon

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

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

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

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.
Permalink | Reply |
headers
Fernando Gont | 5 Oct 23:48
Picon
Favicon

Re: draft-ietf-tsvwg-iana-ports-02

Iljitsch van Beijnum wrote:

> 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
> caring about this.

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

Kind regards,
--

-- 
Fernando Gont
e-mail: fernando <at> gont.com.ar || fgont <at> acm.org
(Continue reading)

Permalink | Reply |
headers
Joe Touch | 19 Oct 03:15
Picon
Favicon

Re: [port-srv-reg] draft-ietf-tsvwg-iana-ports-02


Fernando Gont wrote:
...
> 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.

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
Permalink | Reply |
headers
Fernando Gont | 19 Oct 09:12
Picon
Favicon

Re: [port-srv-reg] draft-ietf-tsvwg-iana-ports-02

Joe Touch wrote:

>> 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.
> 
> That technique doesn't expand the ephemeral range. It uses the reserved
> range as ephemeral, 

Did you mean "registered"?

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

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

-- 
Fernando Gont
e-mail: fernando <at> gont.com.ar || fgont <at> acm.org
(Continue reading)

Permalink | Reply |
headers
Joe Touch | 19 Oct 10:58
Picon
Favicon

Re: [port-srv-reg] draft-ietf-tsvwg-iana-ports-02


Fernando Gont wrote:
> Joe Touch wrote:
> 
>>> 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.
>> That technique doesn't expand the ephemeral range. It uses the reserved
>> range as ephemeral, 
> 
> Did you mean "registered"?

Yes.

>> 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.
> 
> 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
> for the ephemeral ports.
(Continue reading)

Permalink | Reply |
headers
Fernando Gont | 19 Oct 12:26
Picon
Favicon

Re: [port-srv-reg] draft-ietf-tsvwg-iana-ports-02

Joe Touch wrote:

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

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

-- 
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
Permalink | Reply |
headers
Joe Touch | 19 Oct 12:33
Picon
Favicon

Re: [port-srv-reg] draft-ietf-tsvwg-iana-ports-02


Fernando Gont wrote:
> Joe Touch wrote:
> 
>>>> 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.
>>> 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.
> 
> 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.

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?

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

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.
(Continue reading)

Permalink | Reply |
headers
Fernando Gont | 19 Oct 12:53
Picon
Favicon

Re: [port-srv-reg] draft-ietf-tsvwg-iana-ports-02

Joe Touch wrote:

> It'd be useful to consider whether there are actually 15K connections
> 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
> implementing port reuse checks that prevent a port from being used for
> 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.

>> 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?
> 
> And only 6,000 of those 50K are even assigned. 

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

> Again, though, making the
(Continue reading)

Permalink | Reply |
headers
Joe Touch | 19 Oct 13:04
Picon
Favicon

Re: [port-srv-reg] draft-ietf-tsvwg-iana-ports-02


Fernando Gont wrote:
> Joe Touch wrote:
> 
>> It'd be useful to consider whether there are actually 15K connections
>> 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.

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

>> or whether the hosts are incompletely
>> implementing port reuse checks that prevent a port from being used for
>> 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.

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
(Continue reading)

Permalink | Reply |
headers
Eliot Lear | 19 Oct 17:29
Picon
Favicon

Re: [tsvwg] [port-srv-reg] draft-ietf-tsvwg-iana-ports-02

I'm confused.  Outbound and inbound port numbers are complete separate 
name spaces, aren't they?
Permalink | Reply |
headers
Joe Touch | 19 Oct 21:39
Picon
Favicon

Re: [port-srv-reg] draft-ietf-tsvwg-iana-ports-02


Eliot Lear wrote:
> I'm confused.  Outbound and inbound port numbers are complete separate
> 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
Permalink | Reply |
headers
Joe Touch | 19 Oct 03:13
Picon
Favicon

Re: [port-srv-reg] draft-ietf-tsvwg-iana-ports-02


Fernando Gont wrote:
...
>...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.

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
Permalink | Reply |
headers
Alfred Hönes | 17 Oct 00:38
Picon

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

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.
(Continue reading)

Permalink | Reply |

Gmane