Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-port-use-01.txt

From: Joe Touch <[email-masked]>
Date: Mon, 11 Mar 2013 11:10:38 -0700

Hi, Lars,

Thanks for your review.

Comments below.

Joe

On 2/27/2013 10:35 AM, Eggert, Lars wrote:
> Hi,
>
> I gave this a quick read; here are some comments.
>
> Lars
>
>
>
>    High-level: Somewhere in this document, we should point out strongly
>    that service names are available FCFS w/o IANA assignment, and are
>    therefore MUCH easier to use when a service needs to be rolled out
>    quickly.
>
>
> Section 4., paragraph 4:
>>        0-1023         0x03FF         Well-Known (a.k.a. 'system')
>>        1024-49151     0x0300-0xBFFF  Registered (a.k.a. 'user')
>>        49152-65535    0xC000-0xFFFF  Dynamic/Private
>
>    1024 is 0x400

Yup.

> Section 5., paragraph 6:
>>        http:51509//www.example.com/
>
>    Actually, it would be http://www.example.com:51509/

Yup.

> Section 7.2., paragraph 0:
>>   7.2. How Many Ports?
>
>    You might want to add in this section that in the past, when the port
>    number space was less crowded, multiple ports were assigned for one
>    service, e.g., X11. However, that does not reflect current practice
>    anymore, and the existence of such assignments in the IANA table does
>    not constitute a precedent.

Yes. There are at least two cases of this - one where groups were 
assigned before best practices were widely understood, and another when 
the assignments were not as ardently reviewed.

> Section 7.3., paragraph 5:
>>     >> Developers SHOULD NOT apply for system ports because the
>>     increased privilege they provide is not always enforced.
>
>    Developers CANNOT simply apply for system ports since RFC6335 was
>    published. It very clearly says that the policy is "IETF Review" or
>    "IESG Approval" only, and that a "...request for a System Port number
>    MUST document *both* why using a port number from the Dynamic Ports
>    range is unsuitable *and* why using a port number from the User Ports
>    range is unsuitable for that application.

Developers can apply for a system port by following the processes you 
note. The text above suggests that even though such avenues are 
available, they are probably better avoided anyway.

I will clarify and include some of your points as well in the next revision.

> Section 7.3., paragraph 7:
>>     At some future date, it might be useful to deprecate the distinction
>>     between system and user ports altogether, but merely avoiding system
>>     ports would potentially waste only approximately 180 of 1024 values
>>     (17%).
>
>    You might want to add somewhere in this section that many services
>    that need to bind to a system port go through great lengths in order
>    to drop root privileges as soon as they have bound, in order to reduce
>    their attack surface. So it's actually MORE secure to run on a port >
>    1023.

Yes.

> Section 7.6., paragraph 7:
>>     >> UDP multi-host services SHOULD use multicast rather than
>>     broadcast.
>
>    This suggestion isn't really about port use, and therefore maybe not
>    in scope of this document.

It's about how to use ports, which includes whether to use them for 
broadcast or multicast IMO. I.e., requesting a port solely for broadcast 
has severe limitations.

> Section 7.6., paragraph 8:
>>     Designers should be very careful in creating services over
>>     transports that do not support congestion control or error recovery,
>>     notably UDP. There are several issues that should be considered in
>>     such cases:
>
>    Ditto. As much as I'd like a "how to design an application protocol"
>    BCP, this one isn't it. Much of the UDP-specific stuff is also already
>    discussed in more detail in RFC5405.

I can cite RFC5405. However, this too falls into the kind of advice we 
give for those applying for ports, and the things we check.

This is advice for application designers and how they use ports. It's 
not best-practices for apps in general, but some of those considerations 
come into play when asking for a port assignment.

> Section 7.7., paragraph 4:
>>     Deployments that use ports before deployment complicate IANA
>>     management of the port space. Keep in mind that this recommendation
>>     protects both other parties and you; it helps ensure that your
>>     desired number and service name are available when assigned. The
>>     list of currently unassigned numbers is just that - *currently*
>>     unassigned. It does not reflect pending applications, nor
>>     applications that might arrive before yours. Waiting for an official
>>     IANA assignment reduces the chance that your assignment will
>>     conflict with another deployed service.
>
>    You might want to say something about how long an IANA allocation
>    typically takes to process.

Certainly - will do.

---