Subject: Re: [tsvwg] [Fwd: Re: AD review: draft-ietf-tsvwg-port-randomization-05]

From: Lars Eggert <[email-masked]>
Date: Mon, 11 Jan 2010 09:45:32 +0200

[Resending with a CC to TSVWG.]

Hi,

everything that I removed in the reply I agree with your resolution to.

On 2010-1-11, at 7:46, Fernando Gont wrote:
>> It would be good to find a more precise title. Maybe "Transport
>> Protocol Port Randomization Recommendations" or something along those
>> lines?
> 
> I have no issues with your proposed title. Unless I receive any
> objections or alternative proposals for the title, I will apply the one
> you have suggested.
> 
> FWIW, how about "Recommendations for selecting ephemeral ports in
> transport protocols"?

Also good.

>> Section 1., paragraph 1:
>>> Recently, awareness has been raised about a number of "blind"
>>> attacks (i.e., attacks that can be performed without the need to
>>> sniff the packets that correspond to the transport protocol
>>> instance to be
>> 
>> By "instance" you mean "connection"? I'd mildly prefer to use
>> connection, esp. since you don't use the term "instance" consistently
>> in the document anyway.
> 
> "instance" is more generic ("connection" implies connection-oriented
> protocol)... and port randomization has been relevant for connectionless
> protocols, too, . e.g., it has received its share of attention as a
> result of the Kaminsky vulnerabilities found a couple of years ago.
> That's why, if possible, I'd prefer to try to use the term "instance"
> consistently.

OK, but then please search for the term "connection" and check if you want to make it "instance." I don't remember if the term "instance" is defined anywhere yet, if not, maybe you should add one sentence when you first use it.

>> Section 1., paragraph 8:
>>> The mechanisms described in this document are local modifications
>> 
>> Nit: s/local/local, sender-side/
> 
> Sender-side sounds a little bit confusing to me. One might change it to
> "*client* side"... but then some protocols (notably FTP) use ephemeral
> ports on the server side. So I left this one "as is" (please yell if you
> feel strongly about this change).

No, makes sense on second thought.

>> Section 2., paragraph 0:
>>> 2.  Ephemeral Ports
>> 
>> I don't really understand the purpose of Section 2. Almost all
>> content is again covered in Section 3.
> 
> It provides an introduction to ephemeral port selection algorithms. It
> describes the traditional BSD ephemeral port selection algorithm, a
> number of issues (e.g., collisions of connection-id's that are relevant
> for any ephemeral port selection algorithm (even non-random ones))

Right but then isn't there redundancy in Section 3?

>> Section 2.1., paragraph 5:
>>> The range for assigned ports managed by the IANA is 0-1023, with
>>> the remainder being registered by IANA but not assigned.
>> 
>> This is from the IANA web page, but I think it's actually incorrect.
>> IANA manages the entire range 0-65536, and makes assignments in the
>> 0-49151 range, with the 49152-65536 range being unassignable.
> 
> IIRC, ports in the range 1024-49151 are not assigned. IANA just
> registers their use (i.e., what port is being used, and what for).

I checked with IANA, and the page is incorrect. See separate email.

>> Section 2.1., paragraph 6:
>>> The ephemeral port range defined by IANA has traditionally
>>> consisted of the 49152-65535 range.
>> 
>> Not only "traditionally" - it is still defined to be that range.
> 
> Isn't this implied in the sentence? (i.e., the text says "has..." rather
> than "was...").

No, "has...consistent" as a tense means "but now it doesn't anymore". Just say "consists of"?

>> Section 2.2., paragraph 6:
>>> if (five-tuple is unique) return port;
>> 
>> This syntax doesn't really make it clear that the "five-tuple is
>> unique" check uses is done with "port" as the candidate ephemeral
>> port. (Also elsewhere.)
> 
> I couldn't parse your comment. Do you mean we should clarify what we
> mean by "five-tuple", or what?

No, I meant that if the operation you summarize by "five-tuple is unique" checks a five-tuple where the "port" variable is used. I'm sure that it is. Maybe call the check "resulting five-tuple is unique"?

>> Section 2.3., paragraph 0:
>>> 2.3.  Collision of connection-id's
>> 
>> What is a connection-id? Hasn't been defined so far and isn't defined
>> in this section either.
> 
> It's a short-hand for "five-tuple"... But now I realize that
> "connection-ID" would imply "connections" (i.e., CO protocols). So...
> maybe I should change this to "instance-id"? (as a short-hand... and
> provided I have defined the term first, of course).

Yes, that would be better.

>> Section 2.3., paragraph 3:
>>> Another possible approach to minimize the rate of collisions of
>>> connection-id's would be for both end-points of a TCP connection to
>>> keep state about recent connections (e.g., have both end-points
>>> end up in the TIME-WAIT state).
>> 
>> I wouldn't call this a "possible" approach. It has significant
>> drawbacks that make it unsuitable for real deployments (state
>> explosion at servers). It's at best a strawman.
> 
> Completely agree with your pov. -- I just added this one in response to
> wg feeedback/request. However, this approach *is* implented by Cisco IOS.

Right, so don't call it "possible", call it "naive" or something like that :-)

>> Section 3.1., paragraph 10:
>>> Port numbers that are currently in use by a TCP in the LISTEN state
>>> should not be allowed for use as ephemeral ports.
>> 
>> This policy is TCP-specific. Can we broaden this to other transport
>> protocols?
> 
> I'm working on text on SCTP.... (Short answer: SCTP does not allow an
> app to bind() an already-bound port number, unless a specific socket
> option is previously issued). TCP does not preclude this (its API
> specification is much more abstract).

What about DCCP? Or can we broaden this text to in general say that for connection-oriented transports, any port numbers for such instance in the LISTEN (or equivalent) state should not be included?

>> Section 3.1., paragraph 13:
>>> 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 [CPNI-TCP]
>>> [I-D.gont-tcp-security].
>> 
>> This is again entirely about TCP. Do similar issues not exist for
>> other transport protocols?
> 
> Same as above (working on text, and same "short answer").

Same as above, maybe rephrase this to be about connection-oriented transports in general and use TCP as an example?

>> Section 3.2., paragraph 1:
>>> As mentioned in Section 2.1, the ephemeral port range has
>>> traditionally consisted of the 49152-65535 range.
>> 
>> It *still* consists only of that range.
> 
> How about "the port range defined by IANA to be used for the ephemeral
> ports consists..."?

See above.

>> Section 3.2., paragraph 2:
>>> However, it should also include the range 1024-49151 range.
>> 
>> You're mixing two things here: (1) the ranges for which IANA has
>> different allocation rules for and (2) which range the host should
>> randomize over. I understand that you want to say that (2) should be
>> larger than the ephemeral range in (1), but that is *not* the same as
>> making the ephemeral range larger.
> 
> Well, IIRC, IANA does not use the term "ephemeral ports". So, if that's
> the case, the "dynamic port range" is the rannge for which IANA has
> "different allocation rules", while "ephemeral port range" is the range
> that's actually used for outgoing connections. (even with this reasoning
> in mind, I realize the text should be tweaked).

Good point re: IANA not using ephemeral. For the dynamic ports, IANA actually has *no* allocation rules (rather than different ones), but I believe we're clear on the rephrasing needed.

>> Section 3.2., paragraph 3:
>>> Since this range includes user-specific server ports, this may not
>>> always be possible, though.
>> 
>> It doesn't just include "user specific server ports" - it includes
>> ports that IANA has assigned.
> 
> Would rephrasing the text as "... it includes user-specific ports and
> port numbers registered by IANA..." address the issue you have raised?
> (note my s/assigned/registered/)

Sure. (BTW, assigned = registered, at least as far as I know.)

> Anyway, I don't think one should care about a port number that has been
> registered by IANA, but rather about services that are expected to be
> run by the system in question. e.g., my OpenSolaris system should
> probably not care about the fact that some specific port has been
> registered/assigned_to a MS-Windows-specific service.

Right. The only concern here is that some middleboxes (firewalls) erroneously believe that protocols most only use the port assigned to them and so could get confused.

>> Section 3.3.1., paragraph 2:
>>> next_ephemeral = min_ephemeral + (random() % num_ephemeral);
>> 
>> You need to say somewhere what you expect random() to return.
> 
> I used random() as C's random() function. Please let me know if you
> still think I should clarify this.

Yes, because your pseudo code is not obviously C-based.

>> Section 3.3.1., paragraph 14:
>>> This algorithm selects ephemeral port numbers randomly and thus
>>> reduces the chances of an attacker of guessing the ephemeral port
>>> selected for a target connection.  Additionally, it prevents
>>> attackers from obtaining the number of outgoing connections
>>> established by the client in some period of time.
>> 
>> It sounds like you should move this paragraph up to the beginning of
>> this discussion.
> 
> Each section provides this "summary at the end of the section" (that's
> just how we have structured the document). Unless you feel strongly
> about this, I'd leave the text as is (just to avoid shuffling the
> document at this point in time).

Right, but I think my point was that this text equally applies to all randomization schemes?

>> Section 3.3.3., paragraph 1:
>>> We would like to achieve the port reuse properties of the
>>> traditional
>> 
>> When you say "we would like <x>" a number of times in this section,
>> it's not clear if you mean "it could be beneficial to have one
>> algorithm with property <x>" or "we would like <x> for all
>> algorithms." I assume the former, but it's not clear and can be
>> better phrased.
> 
> I think that that depends on the context. e.g.:
> 
>> We would like to achieve the port reuse properties of the traditional
>> BSD port selection algorithm (described in Section 2.2), while at
>> the same time achieve the obfuscation properties of Algorithm 1 and
>> Algorithm 2.
> 
> means that those properties would be beneficial in every obfuscation
> algorithm.
> 
> OTOH,
> 
>> Ideally, we would like a 'next_ephemeral' value for each set of
>> (local IP address, remote IP addresses, remote port), so that the
>> port reuse frequency is the lowest possible.
> 
> discusses how those properties could possibly be achieved by tweaking
> the traditional BSD ephemeral-port selection algorithm.
> 
> Nevertheless, I will try to tweak the text to address this issue you
> have raised.

OK, great.

>> Section 3.3.3., paragraph 15:
>>> The local IP address and remote port may in some cases be constant
>>> and not improve the connection separation, however, they should
>>> also be included in the offset calculation.
>> 
>> What do you mean by "separation"?
> 
> I s/connection/ephemeral port space/
> 
> Separation means that while the port range is still the same,
> connections to different endpoints make independent use of that range
> (the idea of "separation" was already described in RFC1948)

Hm. The only two times the "separa*" shows up in 1948 is when it talks about sequence number spaces, not port number spaces. I'm confused now. Can you attempt to phrase this differently?

---

From: Fernando Gont <[email-masked]>
Date: Mon, 11 Jan 2010 19:42:16 -0300

Hello, Lars,

Comments in-line (I have removed every issue that needed no further
discussion for closure).

>> It provides an introduction to ephemeral port selection algorithms.
>> It describes the traditional BSD ephemeral port selection
>> algorithm, a number of issues (e.g., collisions of connection-id's
>> that are relevant for any ephemeral port selection algorithm (even
>> non-random ones))
> 

I don't think so. Section 2 focuses on interoperability issues. Section
3 focuses on security issues (how to do port randomization). There may
be some overlap, but honestly, at this point in time I'd prefer to leave
 this part "as is".

>>>> The range for assigned ports managed by the IANA is 0-1023,
>>>> with the remainder being registered by IANA but not assigned.
>>> This is from the IANA web page, but I think it's actually
>>> incorrect. IANA manages the entire range 0-65536, and makes
>>> assignments in the 0-49151 range, with the 49152-65536 range
>>> being unassignable.

This is still unclear to me. FWIW, Rich Stevens had already made this
distinction in his "TCP/IP Illustrated" series.

>> Isn't this implied in the sentence? (i.e., the text says "has..."
>> rather than "was...").
> 

Ok. Will do.

>> I couldn't parse your comment. Do you mean we should clarify what
>> we mean by "five-tuple", or what?
> 
> No, I meant that if the operation you summarize by "five-tuple is
> unique" checks a five-tuple where the "port" variable is used. I'm
> sure that it is. Maybe call the check "resulting five-tuple is
> unique"?

I have no problem with this. So unless anybody yells about this change,
I'll apply it.

>>>>  connection-id's would be for both end-points of a TCP
>>>> connection to keep state about recent connections (e.g., have
>>>> both end-points end up in the TIME-WAIT state).
>> Completely agree with your pov. -- I just added this one in
>> response to wg feeedback/request. However, this approach *is*
>> implented by Cisco IOS.
> 

FWIW, as far as *I* am concerned, I wouldn't have included this at
all... but I was requested to do so.

(FWIW, still looking for an adjective that would not start yet another
flame war.... May be I could change the text to something along the
lines of "some implementations have done this"? Or maybe this could
misdirect the reader?)

>>>> Port numbers that are currently in use by a TCP in the LISTEN
>>>> state should not be allowed for use as ephemeral ports.
>>> This policy is TCP-specific. Can we broaden this to other
>>> transport protocols?
>> I'm working on text on SCTP.... (Short answer: SCTP does not allow
>> an app to bind() an already-bound port number, unless a specific
>> socket option is previously issued). TCP does not preclude this
>> (its API specification is much more abstract).
> 
> What about DCCP? 

I guess I'll follow the same approach as for SCTP: consult the authors
of the spec.

> Or can we broaden this text to in general say that
> for connection-oriented transports, any port numbers for such
> instance in the LISTEN (or equivalent) state should not be included?

That might make sense. Although... without checking every existing
transport protocol that might be out there, only pointing out the
specific protocols with which there would be issues seems safer.

>>>> "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 [CPNI-TCP] 
>>>> [I-D.gont-tcp-security].
> Same as above, maybe rephrase this to be about connection-oriented
> transports in general and use TCP as an example?

Might make sense (not sure what to do about this). The difference is
that with e.g., TCP, the spec doesn't preclude you from bind()ing a port
that is already in use, whereas in SCTP it does.

>>> different allocation rules for and (2) which range the host
>>> should randomize over. I understand that you want to say that (2)
>>> should be larger than the ephemeral range in (1), but that is
>>> *not* the same as making the ephemeral range larger.
>> Well, IIRC, IANA does not use the term "ephemeral ports". So, if
>> that's the case, the "dynamic port range" is the rannge for which
>> IANA has "different allocation rules", while "ephemeral port range"
>> is the range that's actually used for outgoing connections. (even
>> with this reasoning in mind, I realize the text should be tweaked).
> 
> Good point re: IANA not using ephemeral. For the dynamic ports, IANA
> actually has *no* allocation rules (rather than different ones), but
> I believe we're clear on the rephrasing needed.

I will tweak the text, and post it to the list in advance (before
resubmitting the I-D) to see if we agree on the changes.

>>>> Since this range includes user-specific server ports, this may
>>>> not always be possible, though.
>>> It doesn't just include "user specific server ports" - it
>>> includes ports that IANA has assigned.
>> Would rephrasing the text as "... it includes user-specific ports
>> and port numbers registered by IANA..." address the issue you have
>> raised? (note my s/assigned/registered/)
> 

As I mentioned, this difference was even made back when Rich Stevens
authored the "TCP/IP Illustrated" series.

>> Anyway, I don't think one should care about a port number that has
>> been registered by IANA, but rather about services that are
>> expected to be run by the system in question. e.g., my OpenSolaris
>> system should probably not care about the fact that some specific
>> port has been registered/assigned_to a MS-Windows-specific service.
> 
> Right. The only concern here is that some middleboxes (firewalls)
> erroneously believe that protocols most only use the port assigned to
> them and so could get confused.

I'd argue that firewalls might be concerned if a *SYN* segment with a
weird TCP Destination Port is received. However, in this case these
ports would not be used that way (i.e, SYN segments would contain these
ports in the *Source* Port field). Also, real-world implementations
already use port numbers in most of the range 1024-65535, so we're not
changing the current state of affairs "problem-wise". (e.g., Windows
uses 1024-4999, FreeBSD uses 10000-65335, etc.).

> Yes, because your pseudo code is not obviously C-based.

Ok, will do.

>>>>  reduces the chances of an attacker of guessing the ephemeral
>>>> port selected for a target connection.  Additionally, it
>>>> prevents attackers from obtaining the number of outgoing
>>>> connections established by the client in some period of time.
>>> It sounds like you should move this paragraph up to the beginning
>>> of this discussion.
>> Each section provides this "summary at the end of the section"
>> (that's just how we have structured the document). Unless you feel
>> strongly about this, I'd leave the text as is (just to avoid
>> shuffling the document at this point in time).
> 

No, it does not. For example, with the simple-hash algorithm it would be
possible for an attacker to obtain the rate of outgoing connections, as
there's a single (and *global*) variable that provides the "increments".
This is not the case for the "double-hash" algorithm, or for the other
randomization schemes (the two "simple randomization" approaches, and
the "random increments" one).

>>>> The local IP address and remote port may in some cases be
>>>> constant and not improve the connection separation, however,
>>>> they should also be included in the offset calculation.
>> connections to different endpoints make independent use of that
>> range (the idea of "separation" was already described in RFC1948)
> 
> Hm. The only two times the "separa*" shows up in 1948 is when it
> talks about sequence number spaces, not port number spaces. 

Exactly. That's because RFC1948 uses the hash-based scheme to "separate
the sequence number space" and we're using the same idea to "separate
the port number space". That is, this approach for obfuscating the
ephemeral ports parallels the approach in RFC1948 to obfuscate the
sequence numbers -- hence the parallel terminology "separation of the
sequence number space" vs. "separation of the

> I'm
> confused now. Can you attempt to phrase this differently?

Please let me know if the clarification I have made about this changes
your mind, or if you still feel that the text should be tweaked.

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

---

From: Lars Eggert <[email-masked]>
Date: Wed, 13 Jan 2010 10:44:05 +0200

Hi,

> be some overlap, but honestly, at this point in time I'd prefer to leave

OK. Unless others feel a need for changes, leave it for now.

> distinction in his "TCP/IP Illustrated" series.

Can you point my at the volume & page number?

> lines of "some implementations have done this"? Or maybe this could

"simple but inefficient"?

> uses 1024-4999, FreeBSD uses 10000-65335, etc.).

OK. Is this briefly discussed anywhere in the doc? (Can't remember.)

> sequence number space" vs. "separation of the

OK, so that point was completely lost on me when I read the document, and simply saying "1948" didn't make it any clearer. If you want to make this point in the document I think you need to be more verbose.

Lars

---

From: Fernando Gont <[email-masked]>
Date: Wed, 13 Jan 2010 15:29:36 -0300

Lars Eggert wrote:

>> This is still unclear to me. FWIW, Rich Stevens had already made
>> this distinction in his "TCP/IP Illustrated" series.
> 

I have not been able to find the page number quickly. But it was
certainly in Vol I.

Goolgle shows that other books make that distinction, too. See, e.g.
(http://docstore.mik.ua/orelly/networking_2ndEd/tcp/ch02_06.htm):

> Port numbers below 1024 are reserved for well-known services (like
> FTP and Telnet) and are assigned by the IANA. Well-known port numbers
> are considered "privileged ports" that should not be bound to a user
> process. Ports numbered from 1024 to 49151 are "registered ports."
> IANA tries to maintain a registry of services that use these ports,
> but it does not officially assign port numbers in this range. The
> port numbers from 49152 to 65535 are the "private ports." Private
> port numbers are available for any use.

Kind regards,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 15 Jan 2010 06:02:54 -0300

Hello, Lars,

>>>>>> Another possible approach to minimize the rate of
>>>>>> collisions of connection-id's would be for both end-points
>>>>>> of a TCP connection to keep state about recent connections
>>>>>> (e.g., have both end-points end up in the TIME-WAIT state).
>>>>>> 
>>>>> I wouldn't call this a "possible" approach. It has
>>>>> significant drawbacks that make it unsuitable for real
>>>>> deployments (state explosion at servers). It's at best a
>>>>> strawman.
>> (FWIW, still looking for an adjective that would not start yet
>> another flame war.... May be I could change the text to something
>> along the lines of "some implementations have done this"? Or maybe
>> this could misdirect the reader?)
> 

Sounds reasonable. Unless anybody yells about this, I will apply this
change.

>>>> Anyway, I don't think one should care about a port number that
>>>> has been registered by IANA, but rather about services that are
>>>>  expected to be run by the system in question. e.g., my
>>>> OpenSolaris system should probably not care about the fact that
>>>> some specific port has been registered/assigned_to a
>>>> MS-Windows-specific service.
>>>  erroneously believe that protocols most only use the port
>>> assigned to them and so could get confused.
>> I'd argue that firewalls might be concerned if a *SYN* segment with
>> a weird TCP Destination Port is received. However, in this case
>> these ports would not be used that way (i.e, SYN segments would
>> contain these ports in the *Source* Port field). Also, real-world
>> implementations already use port numbers in most of the range
>> 1024-65535, so we're not changing the current state of affairs
>> "problem-wise". (e.g., Windows uses 1024-4999, FreeBSD uses
>> 10000-65335, etc.).
> 

No. However, if you feel strongly about this, I could add a small paragraph.

>>>>>> constant and not improve the connection separation,
>>>>>> however, they should also be included in the offset
>>>>>> calculation.
>> Exactly. That's because RFC1948 uses the hash-based scheme to
>> "separate the sequence number space" and we're using the same idea
>> to "separate the port number space". That is, this approach for
>> obfuscating the ephemeral ports parallels the approach in RFC1948
>> to obfuscate the sequence numbers -- hence the parallel terminology
>> "separation of the sequence number space" vs. "separation of the
> 
> OK, so that point was completely lost on me when I read the document,
> and simply saying "1948" didn't make it any clearer. If you want to
> make this point in the document I think you need to be more verbose.

Ok, will do. Would something along the lines the "explanation" above
(that I wrote in response to one of your posts) do?

Thanks!

Kind regards,

---

From: Lars Eggert <[email-masked]>
Date: Fri, 15 Jan 2010 11:22:58 +0200

Hi,

> No. However, if you feel strongly about this, I could add a small paragraph.

I think that'd be good.

> (that I wrote in response to one of your posts) do?

Yes.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Tue, 19 Jan 2010 10:54:44 +0200

Hi,

> I have not been able to find the page number quickly. But it was

There is some text on pp. 12-13, but nothing that makes a clear distinction IMO. This text is also clearly dated. Remember that the book is from 1994 and the was likely written earlier. (For comparison, RFC1812 was published 1995...)

>> port numbers are available for any use.

In my understanding, this is actually wrong: IANA does officially assign ports in the 1024-49151 range, exactly as they do for the 0-1024 range. The only distinction is that historically, the lower ports were considered privileged, because you needed special permissions to bind to them on many platforms.

I've contacted Michelle off-list and I think she confirmed this, and the intent is to update the boilerplate text on the ports registry web site once draft-ietf-tsvwg-iana-ports is approved.

Lars

---

From: Fernando Gont <[email-masked]>
Date: Tue, 19 Jan 2010 14:23:09 -0300

Hello, Lars,

>>>> This is still unclear to me. FWIW, Rich Stevens had already
>>>> made this distinction in his "TCP/IP Illustrated" series.
> There is some text on pp. 12-13, but nothing that makes a clear
> distinction IMO. 

I do recall text along the lines of "is registered (but not assigned) by
 IANA". IIRC, the idea was that if you were already using a port number,
you'd notify IANA, and they would just keep record of it.

> This text is also clearly dated. Remember that the
> book is from 1994 and the was likely written earlier. (For
> comparison, RFC1812 was published 1995...)

Yes. However, the IANA page seemed to converge with Rich Stevens' book
(and others') in this respect.

> In my understanding, this is actually wrong: IANA does officially
> assign ports in the 1024-49151 range, exactly as they do for the
> 0-1024 range. The only distinction is that historically, the lower
> ports were considered privileged, because you needed special
> permissions to bind to them on many platforms.

Has IANA actually assigned all the ports listed in the port-number file
that fall into that range?? Or did they simply register them (i.e., "Hey
IANA, I'm using port number X for my app... would you include it in your
port-numbers file?")

Thanks!

P.S.: I don't care what we converge to... just that we don't have to go
backwards later on....

Kind regards,

---

From: Michelle Cotton <[email-masked]>
Date: Tue, 19 Jan 2010 11:46:58 -0800

IANA assigns a requested port number if that port number is available.
However there are many instances where folks come to IANA and request a certain port number because they have been using it  and it is already assigned to someone else.

We encourage coming to IANA first before "using" a port number.

I'll have to review the text in its full context and send further comments.

Michelle

On 1/19/10 9:23 AM, "Fernando Gont" <[email-masked]> wrote:

Hello, Lars,

Thanks!

Kind regards,

---

From: Lars Eggert <[email-masked]>
Date: Wed, 20 Jan 2010 11:11:22 +0200

Hi,

On 2010-1-19, at 19:23, Fernando Gont wrote:
> that fall into that range??

Yes.

> Or did they simply register them (i.e., "Hey

As far as I know, ports in both the Well Known and Registered ranges have been subject to Expert Review for at least five years and probably much longer. I have never heard that IANA registered ports on first-come-first-serve basis in any range.

Lars

---

From: Fernando Gont <[email-masked]>
Date: Wed, 20 Jan 2010 19:58:07 -0300

Lars Eggert wrote:

>>>  0-1024 range. The only distinction is that historically, the
>>> lower ports were considered privileged, because you needed
>>> special permissions to bind to them on many platforms.
>> Has IANA actually assigned all the ports listed in the port-number
>> file that fall into that range??
> 
> Yes.

What has been the criteria for assigning port numbers for e.g. closed
protocols? (other than just registering their use)

>> Or did they simply register them (i.e., "Hey IANA, I'm using port
>> number X for my app... would you include it in your port-numbers
>> file?")
> 
> As far as I know, ports in both the Well Known and Registered ranges
> have been subject to Expert Review for at least five years and
> probably much longer. I have never heard that IANA registered ports
> on first-come-first-serve basis in any range.

What type of expert review has been made on, say,
shockwave	1626/tcp  Shockwave
lofr-lm         1752/tcp    Leap of Faith Research License Manager
yo-main         4040/tcp   Yo.net main service
turbonote-1     39681/tcp   TurboNote Default Port

Have there any cases in which use of a port has been rejected? If so,
what has been that reason? And what has been the criteria for actually
"granting" the use of ports (as the above)?

Thanks!

Kind regards,

---

From: Lars Eggert <[email-masked]>
Date: Thu, 21 Jan 2010 10:15:14 +0200

Hi,

> protocols? (other than just registering their use)

this is going a bit offtopic, but I believe that IANA has been using the Expert Review procedure we're describing in iana-ports for many years. (One of the reasons for iana-ports is to document the existing procedures.)

> turbonote-1     39681/tcp   TurboNote Default Port

You'd need to ask IANA and the Expert Reviewers for those registrations.

> Have there any cases in which use of a port has been rejected?

Yes.

> If so, what has been that reason?

Depends :-) Maybe IANA can give some examples.

> And what has been the criteria for actually

Satisfying the Expert Reviewer.

Lars

---

From: Joe Touch <[email-masked]>
Date: Thu, 21 Jan 2010 10:16:43 -0800

> on first-come-first-serve basis in any range.

FWIW, that review goes back to Postel's management of the space. In the
days when he was "IANA", he provided feedback to those requesting ports
in ways very similar to that of the current expert review process.

Even back to his coordination of the space, there were a variety of
reasons requests could be rejected, including over-allocation (e.g.,
"can I have 15 ports"), repeatedly asking for ports when in-band
information could suffice (e.g., for a new version of HTTP), or simply
providing insufficient information (lack of point of contact, no
explanation of the service, to avoid allocating a new port for an
existing service, etc).

Joe

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 Jan 2010 16:11:40 -0300

Michelle Cotton wrote:

> However there are many instances where folks come to IANA and request a
> certain port number because they have been using it  and it is already
> assigned to someone else.
> 
> We encourage coming to IANA first before “using” a port number.

Agreed, but, if IANA actually "assigns" rather than just "register" port
numbers in the "registered" port range, I guess some requests are
approved, and others are rejected... so I wonder what's the criteria for
that... in partcular when port numbers are used by "closed" protocols.

e.g., what has been the criteria for "assigning" say, these port numbers:

Have there any cases in which use of a port has been rejected? If so,
what has been that reason?

Thanks!

Kind regards,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 Jan 2010 16:20:35 -0300

Lars Eggert wrote:

>> What has been the criteria for assigning port numbers for e.g.
>> closed protocols? (other than just registering their use)
> 
> this is going a bit offtopic, but I believe that IANA has been using
> the Expert Review procedure we're describing in iana-ports for many
> years. (One of the reasons for iana-ports is to document the existing
> procedures.)

I have not read your I-D (other than some specific parts). But I believe
that the question I asked is key to the "assigned" vs. "registered"
discussion. If it's not clear what's the criteria for assigning or
rejecting port numbers in a specific range, particularly when an app has
already been using it, I don't think one can go further than saying that
 IANA has "registered" the port.

I recall reading some piece of text at IANA's web site that for the most
part the list of registered for was kinda a "best effort" service to the
community.

>> And what has been the criteria for actually "granting" the use of
>> ports (as the above)?
> 

Hope Michelle (or somebody else from IANA) can help with these ones.

Thanks!

Kind regards,

---

From: Lars Eggert <[email-masked]>
Date: Fri, 29 Jan 2010 11:21:04 +0200

Hi,

is this an issue that needs to be resolved before a revision of port-randomization can be posted? (I'm trying to get as many drafts as possible moving before the next IETF...)

Thanks,
Lars

---

From: Fernando Gont <[email-masked]>
Date: Fri, 29 Jan 2010 12:18:56 -0300

Lars Eggert wrote:

> is this an issue that needs to be resolved before a revision of
> port-randomization can be posted? (I'm trying to get as many drafts
> as possible moving before the next IETF...)

No. The only thing I'm waiting for before posting a rev of the
port-randomization I-D is to get help with the DCCP-specific stuff. I've
sent a few unicast e-mails, but got not response -- hence my last post
to the DCCP mailing-list asking for help.

Thanks,

---

From: Lars Eggert <[email-masked]>
Date: Fri, 29 Jan 2010 22:11:08 +0200

Hi,

> to the DCCP mailing-list asking for help.

great - I just saw that email on the DCCP list.

Thanks,
Lars

---

From: Fernando Gont <[email-masked]>
Date: Fri, 29 Jan 2010 17:16:11 -0300

> great - I just saw that email on the DCCP list.

BTW, I got a confirmation today (off-list) that this DCCP-specific stull
will be taken care of this weekend. So you can expect the next rev of
the port-randomization I-D to be posted this weekend or on monday as the
latest (ditto for tcpm's icmp-attacks).

Thanks for pushing this forward!

Kind regards,