Subject: [tsvwg] ports that have been (widely) used

From: Martin Stiemerling <[email-masked]>
Date: Mon, 22 Apr 2013 17:31:22 +0200

Hi all,

Here is a message from Stephen Farrell (SEC AD). He isn't subscribed to 
the tsvwg list, but had a question when reviewing [1].

I'm personally also interested to see what the people's opinion is.

*************************
I see that you've a draft [1] in progress that offers guidance to
folks who are requesting port allocations.

We've seen a few cases recently where well-meaning folk turned up
and asked for ports to be allocated that have been widely used for
some years. For example [2] is one such where I shepherded the
5742 review.

I think it'd be great if [1] offered guidance to people who are
trying to regularise such situations.

Personally, I would hope that guidance would lean more towards
keeping things working that have been working, but in any case I
think clear IETF consensus guidance would be very useful here no
matter what that guidance is.

Thanks,
Stephen.

[1] http://tools.ietf.org/html/draft-ietf-tsvwg-port-use-01
[2]
https://datatracker.ietf.org/doc/draft-hartmann-default-port-for-irc-via-tls-ssl/

************************

Thanks,

   Martin

-- 
[email-masked]

NEC Laboratories Europe
NEC Europe Limited
Registered Office:
Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB
Registered in England 2832014

---

From: Joe Touch <[email-masked]>
Date: Mon, 22 Apr 2013 14:40:38 -0700

Hi, Stephen (et al.),

> I'm personally also interested to see what the people's opinion is.

[1] is intended for those designing new protocols, not those trying to 
document existing ones.

> matter what that guidance is.

The primary issue here is IANA, not the author.

The question involves squatting vs. IANA process. If the IETF wants to 
jump into this issue, it's deep and murky. My view is that any IANA 
request should stand on its own merit.

The key problem happens when a protocol violates IANA principles and 
squats on ports that have not been assigned to it -- e.g., using 
multiple ports unnecessarily, or squatting on a number that IANA has 
already assigned to another service.

What happens then? If we give the ports to the squatter, then what's the 
point of having IANA review policies? What's the point of requesting an 
IANA assignment anyway, esp. if someone else can come along and take it 
away this way?

Overall, if we are going to have *any* process for IANA assignment 
(which we currently do), then the process needs to be followed first and 
foremost - even if this means we sometimes say "NO" to a protocol that 
is widely used but hasn't followed the process.

If we're not going to do that, please do let me know - I wear a few 
hats, including currently IANA ports review team director - and the 
entire team (including me) has better things to do than perform detailed 
reviews when squatting is a sufficient alternative.

Joe

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 23 Apr 2013 10:19:39 +0100

Hi Joe,

> [1] is intended for those designing new protocols, not those trying to

Yes, I'm asking if it'd be useful to broaden the scope of [1]
to cover this situation.

> request should stand on its own merit.

I'm not sure I get most of the above, but sure, IANA
requests need to stand on their own merit.

Its not clear to me whether or not being widely deployed
for a significant duration is considered meritorious in
the case of a port request that tries to regularise a
squatting case.

> IANA assignment anyway, esp. if someone else can come along and take it

That seems very black and white.

> is widely used but hasn't followed the process.

So its the "sometimes" I'm asking about I guess. Its not clear
to me if this kind of request (squatting + widely-deployed for
a significant duration) gets push-back but is then accepted
if that'd not do damage, or just gets a no.

Note, I'm not saying I know the right answer here or that some
policy needs to change, I'm just asking for more clarity as to
what the policy is and wondering what, if anything, transport
folks think of that.

BTW, I can see why the port experts might prefer this to be
less well defined so they can use their judgement, so even
saying that much would maybe be an answer to my question.

Cheers,
S.

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 23 Apr 2013 15:26:06 +0000

Hi,

> if that'd not do damage, or just gets a no.

there are two arguments here I can think of, and both are valid:

(1) We don't want squatting to be seen as the "easy" way to get a port by just allocating whatever people have squatted on; it would encourage squatting.

(2) We want the IANA list to actually reflect port use out in the wild, and we should therefore allow squatters that want to correct past wrongs to get an official assignment; because otherwise the registry will at some point become irrelevant.

We need to discuss what IANA's approach should be. We *do* need to have a consistent opinion and approach for handling these cases.

Lars

---

From: Joe Touch <[email-masked]>
Date: Tue, 23 Apr 2013 08:39:51 -0700

Hi, Stephen,

> Yes, I'm asking if it'd be useful to broaden the scope of [1]

That seems out of scope for this doc; the doc is for protocol designers. 
Documenting existing cases is a special case and not really the focus 
here - it's actually opposite the focus, because you can't chance 
deployed protocols to accommodate the recommendations noted herein.

> the case of a port request that tries to regularise a

That's the key issue, and it is a judgement call. When a protocol isn't 
conflicting with an existing assignment and largely conforms to existing 
expectations, then the answer is easy. The problem is harder when 
there's a conflict or a clear problem. A good example of the latter is a 
deployed protocol that uses a number of ports rather than one.

> That seems very black and white.

When the current assignment is DNS and the new protocol is "funwidget", 
the answer is simple.

When the situation is reversed, esp. when nobody knows the deployment 
state of "funwidget", it's not so easy.

And there are lots of gradations in between.

> if that'd not do damage, or just gets a no

It depends. Both have happened. But we do need to be careful about 
allowing exceptions to current reviewer guidelines because every 
exception is treated as a precedent for the next applicant.

> what the policy is and wondering what, if anything, transport

This document is not guidelines for IANA.

> saying that much would maybe be an answer to my question.

There are many reasons to let it float, among which are:

	- that seems to be the point of 'expert review';
	otherwise we'd just write mechanical rules for IANA staff

	- there are far too many corner cases and grey areas

	- review position does evolve as we all learn,
	so avoiding fixed guidelines allows decisions to include
	more context

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 23 Apr 2013 08:53:10 -0700

> We need to discuss what IANA's approach should be. We *do* need to have a consistent opinion and approach for handling these cases.

While that's true, it needs to be explained in more detail to have 
useful feedback. The following is a start, but IMO the list is too long 
to be detailed.

While it would be useful to get community input, IMO:

	"expert review" != majority rule

The whole point of expert review is handling corner cases and grey 
areas. No single recommendation will handle every case. And I don't see 
utility in replacing one set of experts (the ports review team) with 
another (the IESG).

That said, here is a shortlist of why this is a bit more complex than I 
think is feasible to handle as a group recommendation:

1. what current expectations should IANA allow exceptions to?
	- more than 1 port for a service? more than 5? more than 10?
	- copies of existing services? only for http? for anything
	(e.g., to circumvent firewalls)?

2. how do we handle collisions where a deployed protocol is asking for a 
currently assigned port?
	- what if two deployed protocols both want the same value?
	- how popular does the deployed protocol have to be?
	- how unpopular does the current assignment have to be?

As an example, in one recent IETF case a very popular protocol 
(messaging) that *already had SEVERAL assigned ports* wanted even more 
to accommodate current use. The port creep (using more and more ports) 
happened specifically to get around firewall port blocking, and included 
both additional assigned ports (before the current policy of one per 
service) AND squatting on even more ports.

So what does the community think about that case? Is documenting and 
'legitimizing' this sort of multiport squatting something we should 
support? Is that the price we pay to match current deployment?

----

BTW, if we're going there, let me point out that the IETF should be 
standardizing CUBIC and other non-standard TCP variants as standards 
right now, because they're *deployed*. Even though they don't conform to 
existing standards.

Overall, this highlights a larger tension between standardizing what's 
deployed "to make the standards match reality", vs. making decisions on 
what's appropriate independent of what's deployed. I fall in the latter 
camp. I'd be glad to hear where everyone here is, because it would have 
a huge impact on the IETF process as a whole.

Joe

---

From: David Harrington <[email-masked]>
Date: Tue, 23 Apr 2013 11:55:16 -0400

Hi,

I suggest that it might be good to have the protocol in the wild
documented in an RFC.

That would give the IETF the ability to assign and document an official
port that is recommended, plus acknowledge the squatted port, and
deprecate its use to avoid clashes with officially assigned protocols.
Implementers might want to listen on the deprecated port, and send over it
if necessary to work with legacy listeners deployed in their system, but
prefer the official port, and put pressure on their suppliers to update
their implementation to use the recommended assigned port.

--
David Harrington
[email-masked]
+1-603-828-1401

On 4/23/13 11:26 AM, "Eggert, Lars" <[email-masked]> wrote:

>(1) We don't want squatting to be seen as the "easy" way to get a port by
>just allocating whatever people have squatted on; it would encourage
>squatting.
>
>(2) We want the IANA list to actually reflect port use out in the wild,
>and we should therefore allow squatters that want to correct past wrongs
>to get an official assignment; because otherwise the registry will at
>some point become irrelevant.
>
>We need to discuss what IANA's approach should be. We *do* need to have a
>consistent opinion and approach for handling these cases.
>
>Lars

---

From: Joe Touch <[email-masked]>
Date: Tue, 23 Apr 2013 10:21:54 -0700

Ok, Dave, I'll bite:

How may ports should we continue to assign to that protocol?

Let's say, e.g., it's IRC.

Which already has the following ports for non-secure IRC:

	System:
	194	TCP/UDP

	User:
	6665	TCP
	6667	TCP
	6668	TCP
	6669	TCP

And, at the time, had the following port for secure IRC (over TLS):

	994	TCP

Now, let's hypothetically say we want to document existing use, which 
includes:

	6697	TCP for TLS
	7000	TCP
	8000	TCP

Now, it's very clear that these other, non-assigned ports are being used 
for one or both of the following reasons:

	- to deploy IRC/TLS on a non-system port
	- to circumvent ISPs or other entities that block existing ports
		which also appears to be the reason why ports 6665-6669
		were originally assigned

So how many ports do we continue to dribble out to IRC to support this 
game between system managers and network managers?

At what point do we say "enough"?

IMO, it's never as simple as "documenting what's deployed". Anywhere in 
the IETF. Decisions need to be driven, IMO, from the basic concept of 
where we want things to be, not where operators or implementers happen 
to go.

What we did in this case, which I hope is instructive, is have a very 
long discussion with the ADs and involved parties, and ended up saying 
"6697 and stop squatting on everything else".

First, I think that discussion was beneficial. Second, I think we need 
to be VERY careful about focusing on 'documenting existing practice' 
when it directly conflicts with existing guidelines; what we should try 
to do, as much as possible, is help drive deployments towards existing 
guidelines. Otherwise, again, let's just give up and open the gates now.

Joe

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 23 Apr 2013 18:51:38 +0000

Hi,

On Apr 23, 2013, at 8:53, Joe Touch <[email-masked]> wrote:
> BTW, if we're going there, let me point out that the IETF should be standardizing CUBIC and other non-standard TCP variants as standards right now, because they're *deployed*. Even though they don't conform to existing standards.

we actually tried hard to get CUBIC, Compound and H-TCP to get documented as Informational or Experimental, precisely so that there was accurate documentation on what they were doing. That could have been a first step towards an *eventual* standardization. That entire effort fizzled.

But at least in my mind, assigning a port is NOT the same as standardization. I think it is fully OK to have IANA assign ports to multiple competing services that are being deployed or are being implemented.

Lars

---

From: Joe Touch <[email-masked]>
Date: Tue, 23 Apr 2013 11:54:14 -0700

> But at least in my mind, assigning a port is NOT the same as standardization. I think it is fully OK to have IANA assign ports to multiple competing services that are being deployed or are being im…

Sure - and that's not a problem when an assignment follows the existing 
expectations for assigned services. But it is basically the same kind of 
problem when it doesn't.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 23 Apr 2013 11:59:09 -0700

Another example that recently came up - should netperf be assigned a port?

The port value was unassigned at the time, but the request was one that 
IMO would never have qualified had it not been in widespread use:

	- netperf experiments are always setup explicitly on both ends
	so there's no need for a preassigned port

I.e., it would be preferred to have netperf have a default port in the 
dynamic range, where collisions of port use could be reported by the 
application (i.e., "error - port in use; pick another port using the -p 
option").

There was simply no rationale for assigning a port to this experimental
service other than "it's already in widespread use".

I recommended that no port be assigned; I was overridden by the IESG, 
and we burned a port on this.

Sure, one port isn't much, but I still don't see the point of favoring 
inappropriate widespread use over the existing principles of "ports are 
only assigned where needed".

Joe