Subject: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June)

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 22 May 2014 07:35:48 +0100

This email announces the start of a working group last call to
confirm publication of "Recommendations for Transport Port Uses".

The TSV WG is requesting feedback on this document with the intention to 
proceed to publish this as a BCP.

Please send any comments to the TSVWG list ([email-masked]).

The draft is available at:
http://tools.ietf.org/html/draft-ietf-tsvwg-port-use-04

The last call will run for TWO weeks, ending midnight 5th June.

James, David, and Gorry
(TSVWG Chairs)
[email-masked]

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 22 May 2014 12:25:31 +0000

Hi,

I think this is mostly ready. I do have a few comments (below) that I'd like to see addressed before this progresses.

Lars

  Meta-comment: It would be good to be a bit more consistent with terms.
  The terms "port" and "port number" are used interchangeably in the
  document, although Section 3 clearly describes their difference. Maybe
  do a pass over the doc and check whether you really meant "port" and
  not "port number" wherever the term is used?

Section 1., paragraph 1:
>    This document provides information and advice to system designers on
>    the use of transport port numbers and services.

  "And services" - do you mean service names?

Section 3., paragraph 10:
>    In [RFC820] those range meanings disappeared, and a single list of
>    assignments is presented. By [RFC900] the ranges appeared as decimal
>    numbers rather than the octal ranges used previously. [RFC1340]
>    increased this range from 0..255 to 0..1023, and began to list TCP
>    and UDP port assignments individually (although the assumption was,
>    and remains, that once assigned a port applies to all transport
>    protocols, including TCP, UDP, recently SCTP and DCCP, as well as
>    ISO-TP4 for a brief period in the early 1990s).

  I'm not sure about the "and remains" part. RFC 6335 changed the
  procedure so that port numbers for protocols not requested become
  reserved, and may eventually be assigned to other services, if we run
  out of space. (See the paragraph beginning with "Effective with the
  publication of this document" in RFC6335 Section 7.2.)

Section 4., paragraph 4:
>       0-1023         0x03FF         Well-Known (also System)
>       1024-49151     0x0400-0xBFFF  Registered (also User)
>       49152-65535    0xC000-0xFFFF  Dynamic (also Private)

  Nit: The naming here is actually backwards with regards to which terms
  we used in RFC6335 - there, we used the terms you have in brackets
  here. It would be nice to stay consistent.

Section 6., paragraph 8:
>       o  Different performance requirements can already be supported
>          using separate connections or endpoints with different
>          capabilities or configurations.

  I don't understand this bullet point.

Section 7.4., paragraph 1:
>    a host over a network, an service can also be the opening through

  Nit: s/an service/a service/

Section 7.6., paragraph 5:
>    >> When UDP is used for discovery of an active TCP service, the UDP
>    service name SHOULD end in "-disc".

  This is slightly stronger than what RFC6335 says ('Names referring to
  discovery services, e.g., using multicast or broadcast to identify
  endpoints capable of a given service, SHOULD use an easily
  identifiable suffix (e.g., "-disc").' It would be good to be
  consistent.

Section 255.255.255.255, paragraph 2:
>    There are several issues that should be considered in
>    such cases, each summarized from [RFC5405]:

  The bullets below don't summarize RFC5405 accurately (and some bullets
  aren't even in RRC5405). I'd recommend either quoting Table 1 from
  RFC5405 here, or simply pointing there rather than attempting to
  summarize.

Section 255.255.255.255, paragraph 3:
>    >> UDP services SHOULD be rate limited so that they use only nominal
>    network capacity. Users should keep in mind that "nominal" may vary
>    depending on the deployment environment and may be very low.

  That's different from RFC5405. There is no notion of "nominal
  capacity" there.

Section 255.255.255.255, paragraph 4:
>    >> UDP services that use multipoint communication SHOULD be
>    scalable, and SHOULD NOT rely solely on the efficiency of multicast
>    transmission for scalability.

  That's not from RFC5405 - multicast is out of scope there.

Section 255.255.255.255, paragraph 5:
>    >> UDP services SHOULD include congestion detection and back-off.

  Also not fully accurate.

Section 255.255.255.255, paragraph 6:
>    >> UDP SHOULD NOT be used as a performance enhancement over TCP,
>    i.e., to circumnavigate TCP's congestion control.

  That's not in RFC5405 either.

Section 7.7., paragraph 7:
>    Applications made through Internet Draft / RFC publication typically
>    use a placeholder ("PORTNUM") in the text, and use an experimental
>    port number until a final assignment has been made [RFC6335].

  Nit: s/and use an experimental/and implementations use an
  experimental/

Section 7.7., paragraph 8:
>    That
>    assignment is initially indicated in the IANA Considerations section
>    of the document, and is tracked by the RFC Editor. When the RFC
>    reaches the last stages of publication, that request is forwarded to
>    IANA for handling. At that time, IANA typically requests that the
>    applicant fill out the application form on their website, because
>    not every protocol document addresses the information required.
>    "Early" assignments can be made when justified, e.g., for early
>    interoperability testing, according to existing process [RFC4020]
>    [RFC6335].

  I don't think that IANA requires that the form be filled out for
  numbers assigned in RFCs. They get the information from the IANA
  Considerations section, and will notify the authors if that section is
  incomplete.

Section 7.7., paragraph 9:
>    Using this single application process also ensures that IANA has
>    complete information even if the RFC publication is interrupted. For
>    this reason as well, the application should be complete and not
>    refer solely to the Internet Draft, RFC, a website, or any other
>    external documentation.

  See above - I don't think there is a single process here. I think
  ports from IETF Stream RFCs are handled differently.

Section 7.7., paragraph 10:
>    >> Users writing specifications SHOULD use symbolic names for port
>    numbers and service names until an IANA assignment has been
>    completed.

  Suggest to add another recommendation about implementations using the
  experimental ports during this time.

Section 7.8., paragraph 2:
>    Note that there are numerous services that have squatted on such
>    numbers that are in widespread use. Even such widespread de-facto
>    use may not justify a later IANA assignment of that value,
>    especially if either the value has already been assigned to a
>    legitimate applicant or if the service would not qualify for an
>    assignment of its own accord.

  I'd like to add a paragraph here that encourages squatters to come
  clean and properly register their ports. They still need to provide
  the information, and having squatted is not fast path to assignment,
  but I think everyone is better off if the IANA registry is in line
  with reality as possible.

---

From: Joe Touch <[email-masked]>
Date: Thu, 22 May 2014 14:12:16 -0700

Hi, Lars,

Thanks for the scrub.

FWIW, I was also wondering if we should include some more potent 
(anti)advice about squatting, e.g.:

---
Squatted ports remain unassigned, and IANA retains the right to assign 
it to others. Protocol designers are reminded that is is never 
appropriate to use ports that have not been directly assigned [RFC6335]. 
In particular, any unassigned code from the assigned ranges will be 
assigned by IANA, and any conflict will be easily resolved as the 
protocol designer's fault once that happens (because they would not be 
the assignee). This may reflect in the public's judgement on the quality 
of their expertise and cooperation with the Internet community.
---

Other comments addressed below.

Joe

>    not "port number" wherever the term is used?

Good catch; will do.

>    "And services" - do you mean service names?

Yes; will fix.

>    publication of this document" in RFC6335 Section 7.2.)

Agreed; that paragraph was originally written before RFC6335 was 
completed and we decided to formalize assigning only transports 
requested. Will fix.

>    here. It would be nice to stay consistent.

The point of this section is that the original official names were 
Well-Known and Registered, and we only really clarified that those terms 
were ambiguous and should not be used in RFC6335.

So the intent is to end up consistent with RFC6335, but also to explain 
the origin. If this is confusing, I can revise.

>    I don't understand this bullet point.

Some requests have sought two ports - one for high-BW and one for low, 
or one for fast access to processing and one for "everyone else". Those 
sorts of distinctions can me supported in different connections, and 
don't need port numbers as indicators.

I will add text to explain.

>    Nit: s/an service/a service/

Agreed. Will fix.

>    identifiable suffix (e.g., "-disc").' It would be good to be

I'll match the text.

>    RFC5405 here, or simply pointing there rather than attempting to

I'll point there, so that updates to RFC5405 will be carried along.

>    That's different from RFC5405. There is no notion of "nominal

Sec 3.1.2 is what this is intended to refer to. However, if we just get 
rid of the bullet we don't need to clarify.

>    That's not from RFC5405 - multicast is out of scope there.

OK - so we need to keep this one (and not cite RFC5405).

>>     >> UDP services SHOULD include congestion detection and back-off.

That was intended to refer to Sec 3.1.1; again, omitting this bullet and 
referring just to RFC5405 is sufficient.

>    That's not in RFC5405 either.

OK, but that's worth keeping IMO.

>    Nit: s/and use an experimental/and implementations use an

Agreed.

>    Considerations section, and will notify the authors if that section is

I didn't say "requires", but it's not practical to expect IANA to 
translate the contents of an RFC into what's needed for an application. 
IMO, it's much more appropriate to just have the authors fill out the 
form, even if it's not strictly "required".

>    ports from IETF Stream RFCs are handled differently.

See above.

>    experimental ports during this time.

Sure.

>    with reality as possible.

We can ask them to apply, but we need to remind them that their 
application will be considered without regard for their squatting 
(either pro or con). I.e., just because a service is deployed and in 
widespread use does not circumvent IANA procedures, criteria, or decisions.

I'll add text to roughly that effect, unless you disagree or have an 
additional suggestion.

----

---

From: "Black, David" <[email-masked]>
Date: Thu, 22 May 2014 19:05:36 -0400

<WG chair hat OFF>

Some WGLC comments as an individual ...

-- Section 4:

	System ports do not always require special (i.e., 'root') privilege.

Nit "(i.e., 'root')" -> "(e.g., operating system superuser)"

   For clarity, the remainder of this document refers to the port ranges as
   System, User, and Dynamic.

Following up on Lars's comment, please add a statement that these are
the terms used in RFC 6335.

-- Section 5:

   The first purpose requires that each transport connection between a
   given pair of IP addresses use a different pair of ports, but does
   not require either coordination or registration of port use.

Almost, but not quite - insert "that uses the same transport protocol"
after "each transport connection".  Also, I'm not sure that "connection"
is the best word here, e.g., for UDP, but I'm not sure what to do
without making this sentence wordy and unclear.

   This is
   the primary reason for requesting assigned ports with IANA - to have
   a common agreement between all endpoints on the Internet as to the
   meaning of a port.

Insert "default" or "expected" before "meaning", e.g., in light of the
example a couple of paragraphs earlier of running a web server on port
53 instead of port 80.

-- Section 6

      o  If more than one port is desired, consider revising the
         architecture until only one is needed, or, preferably, none.

An example of how to get to "none" would be helpful.  There are examples
in Section 7.1, so a forward reference may suffice.

-- Section 7.1

      o  Ports are not for performance. Performance enhancement can
         occur within separate connections.

That's a bit cryptic.  The first sentence should be expanded to convey the
misuse (e.g., ports for ordinary- and higher-performance variants of the
same service?).

      o  Additional ports are not to replicate an existing service. For
         example, a device is configured using a typical web browser
         then it is a copy of HTTP port 80 and does not warrant a new
         assignment.

Nit: Insert "if" before "a device"
Nit: "it is a copy of" -> "then the port used for configuration is a copy of"
  or -> "then that device configuration service is a copy of the www
  service that is associated with"

	such as the use of TLS or SSL [Hi95] [RFC5246].

Please send the SSL mention and reference to /dev/null before anyone in
the Security Area notices ;-).  The TLS reference will suffice.

NB: [RFC6101] is better reference for SSL 3 than [Hi95].

-- Section 7.2

   Although
   automatic configuration protocols have been proposed and developed,
   system designers cannot yet rely on their presence.

Should reference those protocols, e.g., STUN and TURN.  The current
RTCWEB work looks like a counterexample to the "cannot yet rely"
statement, e.g., see the TRAM WG charter:

	http://datatracker.ietf.org/wg/tram/charter/

-- Section 7.3

   Would a TCP port number assignment be
   needed useful if the corresponding UDP one were unavailable
   (assuming the proposed service needed only a TCP port)?

This question seems backwards.  If the proposed service only needs
a TCP port, why reserve the UDP one?

Nit: "needed useful" -> "useful"
Nit: "needed only" -> "only requires"

   Even so,
   System port assignments have continued at an average rate of 3-4 per
   year over the past 7 years (2007-2013), indicating that the desire
   to keep this distinction continues.

Or that old habits die hard.  I might actually add those words ;-).

   Further, if
   System ports were no longer assigned, it would cost only 180 of the
   1024 system values (17%), or 180 of the overall 49152 assigned
   values (<0.04%).

Attach a date to the number 180, as it will almost certainly change
before this draft is published as an RFC and change "assigned" to
"System plus User".

-- Section 7.4

   Given the current state of cybersecurity in the Internet,

Please cite a reference for that.

   Optional security can penalize performance, requiring additional
   round-trip exchanges before a connection can be established. As
   discussed earlier, ports are a critical resource and it is
   inappropriate to consume assignments to increase performance.

I don't understand the point that this paragraph is trying to make.

-- Section 7.6

I generally agree with Lars's concerns about the relationship of the
material at the end of this section to RFC 5405; I'll leave it to him
to work those out w/Joe.

-- Section 8 Security Considerations

There are additional security considerations in Sections 7.1, 7.3
and 7.4 that should be noted here.

   This document reminds protocol designers that port numbers are not a
   substitute for security,

The single word "security" is a bit vague - what sort of security?

</WG chair hat OFF>

Thanks,
--David

> -----Original Message-----
> From: tsvwg [mailto:[email-masked]] On Behalf Of Gorry Fairhurst
> Sent: Thursday, May 22, 2014 2:36 AM
> To: [email-masked]
> Subject: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June)
>

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 26 May 2014 13:50:34 -0700

This draft, when taken in light of RFC 6335, is completely unnecessary. If
it is moved forward at this time, it will cause harm to the Internet for
absolutely no purpose.

There is no evidence that that port numbers are actually scarce. The number
of new ports assigned in the past decade is tiny. RFC 6335, which is the
current BCP for TCP/UDP port number allocation from just three years ago,
says:

   As noted earlier, only about 9% of the User Port space is currently
   assigned.  The current rate of assignment is approximately 400 ports
   per year, and has remained steady for the past 8 years.  At that
   rate, if similar conservation continues, this resource will sustain
   another 85 years of assignment - without the need to resort to
   reassignment of released values or revocation.

The draft presumes that preservation of port numbers, even when there is in
fact no significant scarcity, is more important than letting Application
and Security Area WGs determine what their ports needs are.  The
information about applications that use one fixed port and then dynamic
ports ignores experience that has revealed significant problems. Even if
there were real scarcity (which the BCP shows that there isn't), it is
impossible to weigh the needs of port scarcity against the need to create
less fragile protocols.

Ten years from now, if more than 25% of the port space is assigned, the
Transport, Applications, and Security Areas can reconsider something like
this document. Until there is any evidence that there is scarcity that
would cause Application and Security Area changes, the idea should be
shelved and not even discussed.

---

From: "Black, David" <[email-masked]>
Date: Tue, 27 May 2014 09:05:56 -0400

Paul,

<WG chair hat on>

Thank you for commenting.  In the hope of framing further discussion,
I have a few process-oriented comments.

The starting point for this discussion should be RFC 6335, especially
Sections 7 and 8 on principles and procedures.

This draft is not intended to modify RFC 6335.  On that basis, I’d
suggest a couple of questions for further discussion (to which I
believe your comments are relevant):

- How/where does this draft appear to modify RFC 6335 and/or otherwise
diverge from the approach set out in that RFC?

- What sort of guidance beyond RFC 6335 would be useful to application
and service designers?

</WG chair hat on>

Thanks,
--David

From: tsvwg [mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: Monday, May 26, 2014 4:51 PM
To: [email-masked]
Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-port-use-04 (to end 6th June)

This draft, when taken in light of RFC 6335, is completely unnecessary. If it is moved forward at this time, it will cause harm to the Internet for absolutely no purpose.

There is no evidence that that port numbers are actually scarce. The number of new ports assigned in the past decade is tiny. RFC 6335, which is the current BCP for TCP/UDP port number allocation from just three years ago, says:

The draft presumes that preservation of port numbers, even when there is in fact no significant scarcity, is more important than letting Application and Security Area WGs determine what their ports needs are.  The information about applications that use one fixed port and then dynamic ports ignores experience that has revealed significant problems. Even if there were real scarcity (which the BCP shows that there isn't), it is impossible to weigh the needs of port scarcity against the need to create less fragile protocols.

Ten years from now, if more than 25% of the port space is assigned, the Transport, Applications, and Security Areas can reconsider something like this document. Until there is any evidence that there is scarcity that would cause Application and Security Area changes, the idea should be shelved and not even discussed.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 27 May 2014 09:17:39 -0700

On Tue, May 27, 2014 at 6:05 AM, Black, David <[email-masked]> wrote:

> - How/where does this draft appear to modify RFC 6335 and/or otherwise diverge
> from the approach set out in that RFC?
>

The draft modifies/diverges from RFC 6335 (a BCP) in at least two
significant ways.

- The draft says that port numbers are scarce, while the RFC says precisely
the opposite. This would be a modification of the existing RFC, albeit
without any numeric support for the change.

- The approach in the RFC is to tell IANA how to register ports. The
approach in this update to the RFC is to restrict protocol developers
through the use of SHOULD and SHOULD NOT statements.

> - What sort of guidance beyond RFC 6335 would be useful to application

None, really. Most new protocols that need one or more ports are pretty
different than what has come before them. It is the responsibility of the
WGs to know the history of protocol design in their field. Any guidance
will inherently be opinionated. For example, many people in the Apps area
think FTP is a great example of the right way to do ports, and many people
in the Apps area think that it is a great example of how to do it wrong.

It might be useful for someone to try to collect a large body of examples
of port multiplexing and multiple port use, but only as long as it stays
unopinionated. Neither Joe nor I would be good candidate editors for that.
:-)

--Paul Hoffman

---

From: Joe Touch <[email-masked]>
Date: Tue, 27 May 2014 11:32:47 -0700

Hi, David,

Thanks for the detailed feedback. Some questions and alternate 
suggestions below. I'll take the security performance issue to a 
separate thread later today.

Joe

> Nit "(i.e., 'root')" -> "(e.g., operating system superuser)"

How is this:

	(i.e., privileged user, typically known as 'root')

("Superuser" is somewhat antiquated, but the notion of privileged users 
is still current AFAICT).

> the terms used in RFC 6335.

Will do.

> after "each transport connection".

Will do.

> Also, I'm not sure that "connection"

Association?

> example a couple of paragraphs earlier of running a web server on port

Will do.

> in Section 7.1, so a forward reference may suffice.

Will do.

> misuse (e.g., ports for ordinary- and higher-performance variants of the

Will do.

> Nit: Insert "if" before "a device"

Will do.

>    service that is associated with"

"then that port"?

> the Security Area notices ;-).  The TLS reference will suffice.

The term SSL is still in widespread use - even the recent discussions of 
heartbleed refer to both. Is there a good reason to not refer to SSL at 
all? or should we say:

	TLS (or its deprecated predcessor, SSL)

?

> NB: [RFC6101] is better reference for SSL 3 than [Hi95].

Will do.

> Should reference those protocols, e.g., STUN and TURN.

Will do.

> The current

Any given system can declare reliance on other features -- that alone 
doesn't mean they're in widespread use and generic designers should do 
the same.

I can clarify this to say:

    Although
    automatic configuration protocols have been proposed and developed,
    system designers cannot yet rely on their widespread presence.

> a TCP port, why reserve the UDP one?

TCP is indeed more typical. The question happens in the following case:

	TCP yyyy - unassigned
	UDP yyyy - assigned

If someone asks for a new assignment, IANA needs to understand whether 
they could assign yyyy for TCP.

> Nit: "needed useful" -> "useful"

It should have said "needed and useful".

> Nit: "needed only" -> "only requires"

Will do.

> Or that old habits die hard.  I might actually add those words ;-).

If it were merely a habit, it wouldn't stand up to IESG review.

> before this draft is published as an RFC and change "assigned" to

I can, but at the rate it's been going it won't change much (I'm hoping 
we'll be done in less than one year).

> Please cite a reference for that.

I had stated it as common knowledge; if it needs a citation, it's better 
to remove the statement IMO.

> I don't understand the point that this paragraph is trying to make.

I'll raise that as a separate thread, as it relates to some feedback 
Pearl provided off-list.

> and 7.4 that should be noted here.

Will do.

> The single word "security" is a bit vague - what sort of security?

Using assigned numbers for port filtering isn't a substitute for 
authentication, encryption, and integrity protection. I'll clarify in 
the revision with more descriptive text, if that works...

---

From: Joe Touch <[email-masked]>
Date: Tue, 27 May 2014 11:41:22 -0700

On 5/26/2014 1:50 PM, Paul Hoffman wrote:
> This draft, when taken in light of RFC 6335, is completely unnecessary.
> If it is moved forward at this time, it will cause harm to the Internet
> for absolutely no purpose.
>
> There is no evidence that that port numbers are actually scarce.

Although that's true (as already noted in RFC6335, and should be cited 
in this doc too) it's only because of the 1:1 feedback that the review 
process has been providing. The intent of this doc is to provide broader 
advice, in a single place, that's been vetted by the entire transport 
community.

...
> The draft presumes that preservation of port numbers, even when there is
> in fact no significant scarcity, is more important than letting
> Application and Security Area WGs determine what their ports needs are.

There is no aspect of this doc that overrides the current assignment 
process, which includes expert review for requests outside the IETF (the 
bulk of the requests, FWIW) and RFC process for those inside WGs.

...
> The information about applications that use one fixed port and then
> dynamic ports ignores experience that has revealed significant problems.

It's still in widespread use in FTP, SIP, etc. The challenges of doing 
so are already noted.

> Even if there were real scarcity (which the BCP shows that there isn't),

FWIW, because these rules have been informally encouraged for decades...

> it is impossible to weigh the needs of port scarcity against the need to
> create less fragile protocols.

I'll certainly highlight better the issue of in-band identifiers and 
protocol fragility.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 27 May 2014 11:43:27 -0700

Some observations...

> Sections 7 and 8 on principles and procedures.

6335 describes IANA process.

This doc is intended to provide users with advice that was deemed beyond 
the scope of 6335.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 27 May 2014 13:32:56 -0700

On 5/27/2014 9:17 AM, Paul Hoffman wrote:
> On Tue, May 27, 2014 at 6:05 AM, Black, David <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     - How/where does this draft appear to modify RFC 6335 and/or
>     otherwise ____diverge from the approach set out in that RFC?
>
>

Again, RFC 6335 is intended as updating IANA procedures; this doc is 
intended as advice to users.

> - The draft says that port numbers are scarce, while the RFC says
> precisely the opposite. This would be a modification of the existing
> RFC, albeit without any numeric support for the change.

Scarce is relative, of course. Right now I count 5847 TCP and 5570 UDP 
numbers, but the total range is 16 bits, and that's not considered a 
large range overall.

> through the use of SHOULD and SHOULD NOT statements.

Both the IETF process and expert review already do this, which is part 
of the only reason we continue to have a large amount of remaining 
space. It's still somewhat common to get requests for 10's-100's of port 
numbers.

>     ____
> different than what has come before them.

That's false based on the application's I've been reviewing for years. 
Again, remember that IETF WG assignments are a very small portion of 
those assigned overall.

 > It is the responsibility of
> the WGs to know the history of protocol design in their field. Any
> guidance will inherently be opinionated. For example, many people in the
> Apps area think FTP is a great example of the right way to do ports, and
> many people in the Apps area think that it is a great example of how to
> do it wrong.

And the WG can override a BCP with cause and argument - just as for any BCP.

The bigger problem is that it's not feasible for every WG to have that 
working knowlege - and the overwhelming number of non-WG requests don't 
benefit from WG guidance anyway.

That's why we have BCPs; by your argument, we would never have any.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 27 May 2014 14:23:59 -0700

Hi, all,

I'd like to raise this as a distinct thread for discussion.

The question is what advice to give regarding secure vs. insecure ports.

 >     inappropriate to consume assignments to increase performance.

Here are the issues, which should be presented in more detail in the 
doc. Comments welcome, of course.

Joe

----
	- given a current non-secure assignment, what if a
	user requests a (new) second port for secure access?

		this is fine, if not a good idea;
		the current (insecure) port is likely
		blocked at many firewalls, and assigning
		a new port that requires security provides
		an opportunity to safely open access to that
		service

	- given a current secure assignment, what
	if a user requests a (new) second port for insecure access?

		it seems like a SHOULD NOT recommendation
		is appropriate; this creates new vulnerability;
		the primary reason would be performance, and
		assigning additional ports primarily for
		performance should be discouraged in this doc,
		as it has historically been for a very long time.

	- should a user request two ports for a new service, one
	secure and one insecure?

		IMO, the secure port is easy, if otherwise
		warranted (not a duplicate of existing service, e.g.),
		but the insecure one similarly creates a new
		vulnerability, and again I would say SHOULD NOT
		request a new insecure port

	- GIVEN a request for an insecure and secure port, what
	are appropriate justifications?

		IMO, separate firewall control is a sufficient
		reason.

		however, performance should not be - i.e., if
		both ports will typically have the same firewall	
		configuration, then only one port is needed
		and security should be negotiated as present/absent
		in-band. The performance impact of that negotation
		(IMO) should not factor into whether an additional
		port should be assigned.

----

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 27 May 2014 14:42:17 -0700

On Tue, May 27, 2014 at 11:41 AM, Joe Touch <[email-masked]> wrote:

> Although that's true (as already noted in RFC6335, and should be cited in
> this doc too) it's only because of the 1:1 feedback that the review process
> has been providing.

Is there any evidence to support the statement that feedback has changed
this for new IETF protocols? If so, it should certainly be cited.

But, regardless, given that you agree that there is no evidence for the
scarcity, the whole reason for this document seems to fall apart. The
advice of "you should consider multiplexing one one port" is fine, of
course; the theme of the first half of the document that the advice comes
from scarcity is not if there is no scarcity.

> The intent of this doc is to provide broader advice, in a single place,
> that's been vetted by the entire transport community.
>

A BCP is not "broader advice": it is a statement of what the IETF believes
to have been proven as best practice. Much of the advice in the document
("systems might require a single port assignment, but rarely require
multiple ports") cannot be proven as a best practice. It is a practice to
consider, but it is not "best".

> bulk of the requests, FWIW) and RFC process for those inside WGs.

That statement is orthogonal with the statement I made. This draft keeps
hammering at the scarcity as a justification for giving advice; the RFC
says there is no scarcity; thus, this document updates the RFC. Removing
all discussion of scarcity and dropping the intended level of this document
to Informational would go a long way to fixing that problem.

> It's still in widespread use in FTP, SIP, etc. The challenges of doing so
> are already noted.

"Noted" but still pushed in the name of scarcity. A less opinionated
discussion of the problems that FTP and SIP have encountered, and a
comparison to protocols that don't have those problems because they use
fixed ports, would be more informational.

> I'll certainly highlight better the issue of in-band identifiers and

Then why even do this at all? That is, if there really is no scarcity, what
value is this document? I have not heard application or security developers
say "we don't know where to find examples of protocols that use ports in
interesting ways, let's look for an RFC that lists them". Once the scarcity
argument is stripped out, and even if the firewalls discussion is brought
up to date (it uses examples that are about a decade out of date), the meat
of the document is "you can design your protocol's use of ports however you
want". This doesn't seem useful, and still could be harmful if used as a
blunt object during IANA review.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 27 May 2014 14:49:55 -0700

Is this new advice based on any actual evidence or even a security analysis?

Further, a statement of "SHOULD NOT request" sounds a hell of a lot more
like a demand than advice. This gets to the crux of my concern of the
document: it feel like the advice is meant to come from on high (namely,
someone who can block IANA requests), not friendly advice from one
developer to another. We went through this in the discussion a few years
ago, and it seemed then that TSVWG didn't agree that such heavy-handed
"advice", particularly without specific justification, was the way to go.

---

From: Joe Touch <[email-masked]>
Date: Tue, 27 May 2014 15:02:47 -0700

> Is this new advice based on any actual evidence or even a security analysis?

It's based on 8 years of running the review team and discussions within 
that team. It's based on the analysis provided.

If you disagree with the analysis, you should present a counterargument.

> like a demand than advice.

What exactly can we *demand* of a user making an application other that 
to provide advice? It's not advice to IANA or the ports team in how to 
make a decision.

> This gets to the crux of my concern of the
> developer to another.

Can you provide a rationale for that claim other than "because Joe Touch 
wrote it"?

> We went through this in the discussion a few years

TSVWG agreed that limiting IANA was not appropriate; this document 
doesn't limit IANA.

And specific justification is provided in the discussion I gave. Again, 
if you disagree with that discussion, please explain.

E.g., do you actually think it's good security practice to create new, 
insecure services? If so, on what basis of good security practice?

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 27 May 2014 15:18:35 -0700

On 5/27/2014 2:42 PM, Paul Hoffman wrote:
> On Tue, May 27, 2014 at 11:41 AM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>
>     Although that's true (as already noted in RFC6335, and should be
>     cited in this doc too) it's only because of the 1:1 feedback that
>     the review process has been providing.
>

IANA didn't maintain information on assignments per year; I've gotten 
them for the time since I've helped manage the assignments.

There were a few distinct assignment periods and associated policies:

	- prior to ICANN, Jon Postel managed them largely as we do now,
	treating them as something to conserve as much as we knew;
	some apps were assigned ranges (notably X Windows) because
	we didn't know better at the time

	- after ICANN (1998), but before the expert review process was
	active (2008)

	- active expert review process (2008-present)

Here is the data from the recent years, measured in requests. Not all 
request are for a single assignment. As you can see, the number dropped 
roughly in half since 2008. I don't have more recent statistics:

Year	submitted	resolved	%
2012	200	        80	       40.00%
2011	187	        88	       47.06%
2010	210	        118	       56.19%
2009	209	        149	       71.29%
2008	257	        166	       64.59%

I've been trying to get some information about the historical assignment 
rate, but it's slow-going. The rate of assignment approvals has dropped 
since we started putting this advice in place.

However, again, this is NOT intended to be new advice; this is simply 
the same style of advice we have been giving on case-by-case basis to 
applicants. In the vast majority of cases, applicants have appreciated 
getting the feedback and it has led to better protocol design IMO. There 
are some corner cases, as there would be with *any* process.

> scarcity, the whole reason for this document seems to fall apart.

Scarcity is a relative measure. There are only 16 bits of port space, 
and yes, it's only 11% used. But we've turned away dozens of requests 
for 10s-100s of ports, and cut a large number of requests for multiple 
ports down to one or two.

> The
> course; the theme of the first half of the document that the advice
> comes from scarcity is not if there is no scarcity.

Your argument seems to stem from the impression that this doc is 
claiming that something changed that necessitates new, urgent conservation.

The reality is that the only reason we've been able to keep down to 11% 
of use is because of ongoing conservation. 16 bits is not a large space.

>     The intent of this doc is to provide broader advice, in a single
>     place, that's been vetted by the entire transport community.
>
>
> A BCP is not "broader advice": it is a statement of what the IETF
> believes to have been proven as best practice. Much of the advice in the
> document ("systems might require a single port assignment, but rarely
> require multiple ports") cannot be proven as a best practice. It is a
> practice to consider, but it is not "best".
>
>     ...
>
>     process, which includes expert review for requests outside the IETF
>     (the bulk of the requests, FWIW) and RFC process for those inside WGs.
>
>
> all discussion of scarcity and dropping the intended level of this
> document to Informational would go a long way to fixing that problem.
>
>
>     ...
>
>     It's still in widespread use in FTP, SIP, etc. The challenges of
>     doing so are already noted.
>
>
> Then why even do this at all? That is, if there really is no scarcity,
> what value is this document? I have not heard application or security
> developers say "we don't know where to find examples of protocols that
> use ports in interesting ways, let's look for an RFC that lists them".
> Once the scarcity argument is stripped out, and even if the firewalls
> discussion is brought up to date (it uses examples that are about a
> decade out of date), the meat of the document is "you can design your
> protocol's use of ports however you want". This doesn't seem useful, and
> still could be harmful if used as a blunt object during IANA review.
>
> --Paul Hoffman

---

From: Joe Touch <[email-masked]>
Date: Tue, 27 May 2014 16:15:42 -0700

Some more recent stats - these count only TCP ports assigned:

	total	new
2000	3081	(na)
2001	3480	400
2002	3925	445
2003	4146	231
2004	4404	258
2005	4652	248
2006	4992	340
2007	5155	163
2008	5317	162	*expert review starts
2009	5456	139
2010	5558	102
2011	5710	152
2012	5764	54	*RFC6335 published
2013	5819	55
2014	5847	28 (to date, roughly on track for ~60)

Note that we didn't actively change anything when RFC 6335 was 
published; it was not used to justify recommending declining requests.

The number of RFC-related requests per year is very small - 5-10 at 
best, AFAIR.

AFAICT, a lot of the reduction has helped keep a lot of junk out of the 
list, e.g., people who - in the absence of advice - ask for 10s-100s of 
ports at a time, or who don't realize that there may be existing 
services that would suffice.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 27 May 2014 16:24:32 -0700

PS - yes, these numbers are good news in terms of management of the 
space, but they could as easily have driven the other way without active 
feedback.

---

From: "Black, David" <[email-masked]>
Date: Tue, 27 May 2014 19:45:52 -0400

Joe,

I'm quoting only those items that I have comments on - everything else 
is fine, including any text suggestions that I don't comment on.

> > without making this sentence wordy and unclear.

Ok, it's better than "connection".

> > NB: [RFC6101] is better reference for SSL 3 than [Hi95].

In that case, let's call SSL "historic" rather than "deprecated" and
reference RFC 6101 ... which just happens to be an Historic RFC ;-).

> they could assign yyyy for TCP.

Rephrasing suggestion:

      Would a TCP port number assignment be useful by itself?  If so, a
      TCP port number can be assigned whose corresponding UDP port
      number is already (or can be subsequently) assigned to a different
      protocol.

This is mostly editorial.

> to remove the statement IMO.

RFCs are archive documents - the "current state" won't be "common knowledge"
10-15 years from now.  I guess you should remove it.

> the revision with more descriptive text, if that works...

That'll work - I think you've written much of what's required in that
response to me.

Thanks,
--David

> From: Joe Touch [mailto:[email-masked]]
> Sent: Tuesday, May 27, 2014 2:33 PM
> To: Black, David; [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Tue, 27 May 2014 16:56:54 -0700

Hi, David,

> Ok, it's better than "connection".

It's the best I have; other suggestions welcome.

Will do.

> This is mostly editorial.

Agreed; will do.

> 10-15 years from now.  I guess you should remove it.

Glad to remove it, though every RFC is a product of the time it is 
published anyway.

> That'll work - I think you've written much of what's required in that

AOK - it needs a little additional text to make sense in context.

Joe

---

From: "Black, David" <[email-masked]>
Date: Tue, 27 May 2014 20:40:55 -0400

Joe,

<WG chair hat OFF>

> If you disagree with the analysis, you should present a counterargument.

Ok, I'll try ... ;-).

It might help if this had somewhat more of a flavor of documenting the
review criteria that are currently used, although I do think at least
one "SHOULD NOT" is likely to turn up in the final text.

I'd certainly like to see some Security Area input (and probably also
OPS, as firewalls play a prominent role), but speaking for myself,
I think offering security advice is well within reason here ...

Going back to the three scenarios at the start of this thread, the
proposals for the first two seem reasonable (IMHO):

I presume that the latter recommendation envisions a scenario where
the secure port has been deployed and used for a significant period
of time.  In that case, I think a "SHOULD NOT" is ok, as I'd want to
see some heavy-duty serious justification for adding the insecure
port.  The draft should state that presumption, though, as deployment
difficulties/experience might result in something closer to the third
scenario.

I suspect that the advice for the this one is likely to be a long
version of "it depends" in practice.

I agree with the secure port being fine, but I'm not comfortable
with a blanket "SHOULD NOT" recommendation for the insecure port.

I think this depends on the details of the protocol.  I'd definitely
set an expectation that solid justification for the new insecure
port will be expected, with the applicant being responsible for
justifying why use of security is not mandatory for the protocol.
If that justification makes the case, then the firewall control
rationale (below) definitely sounds reasonable, IMHO.

I just don't think the level of required justification is going
to rise to that sufficient to override a "SHOULD NOT" for every
single protocol design that we have yet to envision.  I wish my
foresight was 20/20 :-).

		in-band. The performance impact of that negotiation

I think the text on performance should be explicit that the
performance concern is negotiation round trip avoidance.

</WG chair hat OFF>

Thanks,
--David

> Sent: Tuesday, May 27, 2014 6:03 PM
> To: Paul Hoffman
> Cc: Black, David; [email-masked]
> Subject: Re: [tsvwg] additional ports for security - Re: WGLC for draft-ietf-
> tsvwg-port-use-04 (to end 6th June)
> 
> 
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 27 May 2014 18:59:36 -0700

On 5/27/2014 5:40 PM, Black, David wrote:
> of time.

Yes.

> In that case, I think a "SHOULD NOT" is ok, as I'd want to

Right - that's the point of the SHOULD NOT. It's not a MUST NOT. It just 
needs very heavy justification.

> rationale (below) definitely sounds reasonable, IMHO.

Why isn't that a SHOULD NOT? Certainly a bit more text is in order, but 
it seems like we're in agreement - deep justification is needed.

> single protocol design that we have yet to envision.  I wish my

FWIW, there aren't a lot of protocols that ask for secure and insecure 
at the same time. Those come mostly - incredibly - from IETF WGs, where 
they appear to be (IMO blindly) following past practice.

My key concern is "why is the insecure port needed"? Most of the time 
the justification is pure performance - running security on the service 
will make it too slow, and this will allow faster performance inside an 
enterprise. That might be true, but it also needs to be justified in 
terms of the service being provided - that this is a high-throughput or 
high-transaction frequency system that needs high performance inside 
protected enterprises.

> performance concern is negotiation round trip avoidance.

There are a few different performance issues:

	- round-trip delays
	- throughput overhead (per byte)
	- message overhead (per message)

Joe

---

From: Eliot Lear <[email-masked]>
Date: Wed, 28 May 2014 08:02:58 +0200

Hi,

On 5/27/14, 6:17 PM, Paul Hoffman wrote:
>
> None, really. Most new protocols that need one or more ports are
> pretty different than what has come before them. It is the
> responsibility of the WGs to know the history of protocol design in
> their field. Any guidance will inherently be opinionated. For example,
> many people in the Apps area think FTP is a great example of the right
> way to do ports, and many people in the Apps area think that it is a
> great example of how to do it wrong.

I am sure they are the miniscule exception for very practical reasons. 
I would say that each of the expert reviewers has a bit of a catalog of
what to expect in requests for justifications, and we know where the
arguments will usually lead.  Some of this has now been codified in 6335
(discovery and versioning are examples).

>
> It might be useful for someone to try to collect a large body of
> examples of port multiplexing and multiple port use, but only as long
> as it stays unopinionated. Neither Joe nor I would be good candidate
> editors for that.

Any time a protocol supports more than one operation it is an example of
multiplexing, and so the question becomes, “How disparate are those
operations?”  THAT, I'm afraid, is a value judgement, because the answer
is often tied to an application architecture and not specifically to a
network service.  And there I agree with you that we as port reviewers
have to be careful about our judgment versus that of those who are doing
the coding.  What is reasonable to do, and what we have been doing, is
asking the question and seeing that the applicant has at least thought
through the answer.  A lot of the port reviewer job is doing just that-
asking good questions.  What is obvious to us is often not obvious to
the applicant.  I was reminded of this just recently by Joe when an
applicant applied for a port, and it turned out they had a port assigned
that had a reasonable description but was not in fact deployed.  I had
simply assumed they had deployed it.  Doh.  We got a free port back.

Anyway, my point is that Joe's writing this draft from a wealth of
experience.  This having been said, I'll have my own comments on this
draft in a separate note.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Wed, 28 May 2014 08:33:32 +0200

Dear Joe & TSVWG,

I have the following comments about draft-ietf-tsvwg-port-use-04. 
Buried in this review is a question regarding HTTP in particular that
IMHO both this WG and the apps area needs to seriously consider.

When reviewing this document, I asked the question, “Does this text help
me provide me guidance about how to design my services?”  As such, while
it's a very interesting history, I find that Section 3 fails that test.

I am generally not a fan of repeating information in multiple documents,
but if we are going to list port ranges, I would request that we
indicate the authoritative source, which is RFC 6335 Section 6.  The
IETF is the policy authority for this information, not IANA.

The following text in Section 6 of the draft needs serious review:

>    Others have noted "think twice about modifying TCP, then don't"
>    [RFC1263]. In this case, similar advice might be:
>
>       o  Think twice before asking for an assigned port, then try not
>          to.
>

Developers SHOULD request ports to differentiate their services.  The
question is how many ports do they need to do that.  Therefore, the
analogy used to RFC1263 is inappropriate.

In Section 7.1:

>          New services should support security or should consider
>          optional security. A new service should not need a port for an
>          insecure version; at best, this would be a performance issue
>          (see the first bullet), and at worst this presents a new
>          vulnerability.

We should be considering a stronger statement than this with normative
language that is in line with IETF consensus as documented in RFC 7258. 
But we have to be careful to not chase off applicants such that they
squat or inappropriately warp their architecture.  Therefore, I suggest
phrasing that is similar to what is found in RFC 7258.  Let me suggest
two questions to be asked.  The first comes right out of the RFC:

> Is pervasive monitoring relevant to this work and if so, how has it
> been considered?

The second is more general:

How have security considerations been taken into account?

And throw a MUST around at least being able to answer those questions. 
Reviewers can then use their judgment as to the validity of the answers.

Going to the next paragraph:

>
>       o  Ports are not for indicating different service versions.
>          Version differentiation should be handled in-band, e.g., using
>          a version number at the beginning of a connection or
>          transaction. This may not be possible with legacy assignments,
>          but all new assignments should incorporate support for version
>          indication.

This point requires expansion.  We are currently seeing a number of
requests around HTTP in particular in which there is absolutely no
difference between protocol being run on port 80 and what is being
requested.  The reason for the request, however, is that the applicant
is offering some sort of server management function.  The above guidance
says that hosts should multiplex this function on port 80.  As a matter
of architecture, we need to decide what the real guidance should be in
this case.  Should it be require that web servers support such
multiplexing?  We certainly have the means through .well-known, for
instance.

And we have seen similar issues with other popular protocols.  MySQL is
a big hit at the moment.

Eliot

---

From: Pearl Liang <[email-masked]>
Date: Wed, 28 May 2014 08:18:16 -0700

Hi,

I was thinking about that too - can we expand the texts regarding
applications use the generic or redesigned HTTP in this document?

~pl

On 5/27/14 11:33 PM, "Eliot Lear" <[email-masked]> wrote:

>When reviewing this document, I asked the question, ³Does this text help
>me provide me guidance about how to design my services?²  As such, while

---

From: "Black, David" <[email-masked]>
Date: Wed, 28 May 2014 12:32:14 -0400

<WG chair hat OFF>

> it seems like we're in agreement - deep justification is needed.

We're dealing with a process as opposed to a protocol here, so the functionality
of some future protocol that will ask for ports is unknown to us at the moment.

> > the secure port has been deployed and used for a significant period

IMHO, that "running code" deployment and use experience provides a solid
strong foundation for a "SHOULD NOT" by comparison to the "new request
for two ports" case, where a "SHOULD NOT" strikes me as pre-evaluating
protocol design decisions, sight unseen, for protocols that nobody's
even thought of, yet.

> they appear to be (IMO blindly) following past practice.

Here I agree - use of "we've always done it that way" as a rationale SHOULD
be strongly discouraged; beyond that, I'd suggest pointing out that requests
for both ports are viewed with significant skepticism because that reason
has been the primary rationale for many of them.  It would also help to 

</WG chair hat OFF> 

Thanks,
--David

> Sent: Tuesday, May 27, 2014 10:00 PM
> To: Black, David; Paul Hoffman
> Cc: [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Wed, 28 May 2014 09:39:09 -0700

Hi, Eliot,

Thanks for the detailed comments. My view is below...

Joe

> it's a very interesting history, I find that Section 3 fails that test.

The purpose of this document is advice to users on how to use service 
numbers and service names, i.e., how to deal with aspects of service 
design that affect service assignment.

It isn't a course in service design. That would take a book.

> IETF is the policy authority for this information, not IANA.

Agreed; this will be fixed in the next version.

> Developers SHOULD request ports to differentiate their services.

Not necessarily. A service that *can* operate effectively on dynamic 
ports should do so.

> analogy used to RFC1263 is inappropriate.

I disagree. Assigned ports have a real cost in system configuration 
complexity as well as consuming a global community resource, which is 
why the "similar" advice is appropriate here IMO.

> language that is in line with IETF consensus as documented in RFC 7258.

Security includes a breadth of issues including resistance to 
interference, masquerading, content observation, and meta-information 
tracking.

For the purposes of this document, we should be clear that "security" 
typically refers to the first 3, but not the last. In fact, using 
assigned ports is the antithesis of avoiding monitoring - you're 
advertising to the world the service type.

Regardless, IMO it's inappropriate to create RFC 2119-level requirements 
justified by a BCP that has *NO* RFC 2119 recommendations.

> squat or inappropriately warp their architecture.

This has always occurred and will always occur. Although I don't want to 
chase them off, appeasing them is like "adjusting laws for the benefit 
of the lawless".

> Therefore, I suggest

I don't intend to do this for every RFC until a "Pervasive montitoring" 
section is required for submission. Otherwise, we will end up derailing 
*every* RFC with *every* BCP that's *ever* been issued.

This document has nothing to do with avoiding monitoring or enabling it, 
so this issue is IMO out of scope.

> How have security considerations been taken into account?

See Section 8, which will be expanded to include pointers to 
considerations addressed elsewhere in the doc.

> And throw a MUST around at least being able to answer those questions.

There are no MUSTs in RFC 7258.

> multiplexing?  We certainly have the means through .well-known, for

In 1999 HTTP 1.1 added the Host header field, and TLS was extended to 
support this in its SNI for this very purpose.

The issue with HTTP is that it both a presentation layer and an 
application layer at the same time. When used as a presentation layer, 
other protocols can be designed on top and that easily warrants a new 
port. When used as an application layer, the "no duplicate" rule applies.

I.e., server management by custom protocols warrants a new port. Servers 
managed by unmodified web clients should use port 80 or 443.

Otherwise, every web server instance would warrant a new port - and that 
would easily overwhelm the number of available ports. This is we should 
not assign multiple ports to the same service (even though this was done 
in the past, e.g., 8080).

> And we have seen similar issues with other popular protocols.  MySQL is

The MySQL issues are different. That is one of a number of protocols 
that different groups are extending, and each group wants a separate 
port for their extensions. My view of these has been that any 
*independently useful* service qualifies, but that extensions that 
aren't stand-alone aren't services - they're extensions - and extensible 
services should be extended within their assigned port.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 28 May 2014 09:42:28 -0700

> protocol design decisions, sight unseen, for protocols that nobody's

In both cases we're assessing an event in the future - as with *every* 
RFC 2119 recommendation. The SHOULD NOT isn't pre-evaluating - it's 
saying that there are enough concerns with this path that strong 
justification is needed - just like *every* SHOULD or SHOULD NOT exception.

> add discussion of "justified in terms of service provided":

AOK. Rather than SHOULD NOT, I'll go with "extreme skepticism" (although 
I ask others on the list to weigh-in on this - IMO, "extreme skepticism 
for exceptions" is precisely what SHOULD NOT implies).

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 28 May 2014 09:44:33 -0700

> applications use the generic or redesigned HTTP in this document?

There are some hazards with some advice in this document. As much as we 
don't want to scare away squatters unnecessarily, we also don't want to 
give directions for end-runs.

It is certainly useful to discuss the HTTP issue with more text, but I 
would suggest we should avoid going into too much detail with examples 
as a result.

Joe

---

From: "Black, David" <[email-masked]>
Date: Thu, 29 May 2014 11:34:51 -0400

<WG chair hat OFF>

> justification is needed - just like *every* SHOULD or SHOULD NOT exception.

I draw a distinction between the "add an insecure port" case, where we at
least have "running code" for the protocol and the "new request for two ports"
case where there is no "running code" for the protocol and the initial "rough
consensus" (assuming that this is from an IETF WG) runs the other way (i.e.,
towards two ports).

> for exceptions" is precisely what SHOULD NOT implies).

For clarity, I think the "extreme skepticism" should be focused on reliance
upon "we've always done it that way" as the rationale, as opposed to broadly
on all requests for two ports.  IMHO, the latter ought to come across as a
requirement to "show your work" as opposed to strong discouragement of all
requests for two ports.  Independent of the precise wording in RFC 2119, I
would expect "SHOULD NOT" to be read as strong discouragement by a significant
portion of the intended audience.

</WG chair hat OFF>

Thanks,
--David

> Sent: Wednesday, May 28, 2014 12:42 PM

---

From: Joe Touch <[email-masked]>
Date: Thu, 29 May 2014 08:57:26 -0700

...
> consensus" (assuming that this is from an IETF WG) runs the other way (i.e.,

The former is certainly more potentially dangerous than the latter.

> portion of the intended audience.

The problem with "show your work" is that there is no other RFC2119 
language for that, which means it will have no teeth when the request 
comes for the WG.

I.e., in the case where WG rough consensus seeks two ports, that itself 
will be seen as sufficient unless this BCP says otherwise.

Maybe we could say "SHOULD NOT ask for two ports", but add "unless (as 
with any SHOULD-level recommendation) sufficient direct rationale for an 
exception is provided"?

Joe

---

From: "Black, David" <[email-masked]>
Date: Thu, 29 May 2014 13:39:01 -0400

<WG chair hat OFF>

Eliot described an alternative approach:

> Let me suggest

Beyond Eliot's specific questions (which are good, IMHO), I like the idea
of applying 2119 keywords to the port assignment process as opposed to the
protocol design.  Moreover, I'm comfortable with using "MUST" for port
assignment process requirements.

Applying that idea to this discussion, the two key points could be:

- When requesting both a secure and an insecure port, strong
        justification MUST be provided for the insecure port.

- Precedent (citing other protocols that use an insecure port) is not
        strong justification by itself.  A strong case for utility of the
        insecure service is REQUIRED for approval of the insecure port.

The above use of "MUST" and "REQUIRED" make it clear what the WG has to do
if they want to go down this path.

In addition, so we don't lose it:

- Requests for large numbers of ports (e.g., 10s-100s) SHOULD NOT be made,
        as they will be rejected.

In contrast to asking for a secure and an insecure port, this is a case
where a "SHOULD NOT" on protocol design is appropriate, IMHO.

</WG chair hat OFF>

Thanks,
--David

> Sent: Thursday, May 29, 2014 11:57 AM
> To: Black, David
> Cc: [email-masked]
> >>>>>> Subject: Re: [tsvwg] additional ports for security - Re: WGLC for
> draft-
> >>>> ietf-

---

From: Joe Touch <[email-masked]>
Date: Thu, 29 May 2014 11:10:38 -0700

...
>> How have security considerations been taken into account?

The first is related to a BCP with no RFC2119 requirements; it doesn't 
seem appropriate to demand it be separately addressed, as a result.

The latter is already required.

> protocol design.

That would be an update to RFC6335.

This document is intended as guidance for protocol designers.

> Moreover, I'm comfortable with using "MUST" for port

Sure - we did in RFC6335.

> if they want to go down this path.

That's fine. I don't quite see the difference between that an "SHOULD 
NOT ask for two ports", but if you're more comfortable with the above.

>          as they will be rejected.

It'd just as soon say that:

	Each port requested MUST be justified as
	independently necessary.

That would go in the following section, whose advice I think is still 
valid in that context:

We have a couple of SHOULD NOTs still in the doc; some that need to be 
cleaned up (UDP section, security), others that seem valid.

---

From: "Black, David" <[email-masked]>
Date: Thu, 29 May 2014 14:58:42 -0400

<WG chair hat OFF>

> > I like the idea

Well, protocol designers are going to be involved in applying for port
assignments, so the scope of guidance extends to use of that process.

Preferably, an update to RFC 6335 can be avoided by making any use of 2119
keywords consistent with RFC 6335's requirements.  Independent of whether
that happens, the topic of whether this draft updates 6335 and the precise
specifics of what is being updated ought to be secondary to figuring out
what this draft should say and why, IMHO.

> NOT ask for two ports", but if you're more comfortable with the above.

Yes, please.

I think this is on firmer ground focusing on process rather than design of
yet-to-be-envisioned protocols.  In addition, a "SHOULD NOT" on a process
topic is easy to (mis-)read as "Don't even bother trying this, you'll only
succeed in annoying the people whose approval you need."

Thanks in advance for looking at the other instances of "SHOULD NOT" for
similar concerns.

</WG chair hat OFF>

Thanks,
--David

> Sent: Thursday, May 29, 2014 2:11 PM
> To: Black, David
> Cc: [email-masked]
> >>>>>>>>> "advice", particularly without specific justification, was the way
> to
> >>>> go.
> >>>>>>>>

---

From: Eliot Lear <[email-masked]>
Date: Thu, 29 May 2014 21:47:34 +0200

Hi Joe,

> Not necessarily. A service that *can* operate effectively on dynamic

Fair enough, but my point is that the tone of the document is wrong. 
Yes, these are scarce resources, but they are resources that should be
made use of in appropriate circumstances.
> why the "similar" advice is appropriate here IMO.

Yes, they consume a global resource.  Typically, however, it's the other
way around with regard to system configuration complexity, right?  We
get requests all the time in order to avoid configuration.

Yes.
>
> Regardless, IMO it's inappropriate to create RFC 2119-level
> requirements justified by a BCP that has *NO* RFC 2119 recommendations.
>
> This has always occurred and will always occur. Although I don't want
> to chase them off, appeasing them is like "adjusting laws for the
> benefit of the lawless".

This is a tonal issue.  We are here to provide a service to those who
need it.  The document contains a checklist that makes clear that if you
don't answer each of those questions correctly, no port for you.  There
are times when it is entirely appropriate to request a new port.  It's
those people I don't want scared off.

> I don't intend to do this for every RFC until a "Pervasive
> montitoring" section is required for submission. Otherwise, we will
> end up derailing *every* RFC with *every* BCP that's *ever* been issued.

But in considering this draft WE have to consider pervasive monitoring,
and it is fair game to ask the question whether or not we should up the
requirement for at least a justification as to why they're not
encrypting.  But maybe that's a 6335bis?

> I.e., server management by custom protocols warrants a new port.
> Servers managed by unmodified web clients should use port 80 or 443.
>
> Otherwise, every web server instance would warrant a new port - and
> that would easily overwhelm the number of available ports. This is we
> should not assign multiple ports to the same service (even though this
> was done in the past, e.g., 8080).

I think the issue here really is that one cannot assume the ability to
multiplex the service on port 80 or 443.  One cannot require the use of
.well-known on port 80 or 443.

Eliot

---

From: Joe Touch <[email-masked]>
Date: Thu, 29 May 2014 13:44:33 -0700

> made use of in appropriate circumstances.

Point taken. I'll revise, both with the details of the current use and 
tracking, as well as the general principle of conservation but not at 
the expense of obfuscation.

> get requests all the time in order to avoid configuration.

Config complexity is decreased by separating independent services on 
separate ports, but increased by factoring a single service on multiple 
ports.

E.g., it's more complex to configure and debug a system that relies on
multiple ports being opened on a firewall.

Again, good points to raise in the doc.

> those people I don't want scared off.

Good point - I'll check for that tone throughout, and throw in a few 
encouraging words, esp. in the abstract and intro.

> But in considering this draft WE have to consider pervasive monitoring,

we don't *have* to... as I said, this doc isn't aimed at increasing or 
decreasing monitoring per se...

> encrypting.

I was confused by your question; I thought you were talking about this 
doc only, but I think you're saying we should ask those questions to the 
applicant, right?

We already basically do ask what they're doing about security indirectly 
- we should be more direct about that, and that's consistent with the 
need for all RFCs to have a Security Considerations section.

However, I don't think that's independently true for monitoring; if it's 
a security issue, they can address it there, and if not, we should wait 
until RFCs are asked to have a separate monitoring section.

> But maybe that's a 6335bis?

It doesn't have to be; 6553 talks about the information needed for an 
application already. The specific questions we (the Expert Review team) 
ask on the application are really just to facilitate our review, and 
fall under "Description" in 6335.

> multiplex the service on port 80 or 443.

They can - by hostname. (Host field in HTTP).

 > One cannot require the use of

Agreed - those are for other things beyond multipexing, though.

Joe