Initial draft of IANA port assignment form

[BlueHatbRit]

This is the initial draft of the IANA port assignment form. As you might be able to tell, I've not filled one of these out before so I may have missed the point on some of these questions, hence the request for comments and feedback.

In the markdown document I've only listed the questions that we are required to answer. Please see the full form here - https://www.iana.org/form/ports-services to see any questions that have been intentionally skipped. Would be great if someone could also check this in case I've missed something important!

Many of the questions refer to the protocol as opposed to the service.

ccing for review / input: @mheffner, @mrtazz, @lzap. Please feel free to pull in anyone else who might have experience and be interested in helping out.

[lzap]

Good and smooth.

[mheffner]

Looks fine, left a few small comments.

[mheffner]

"...and publishing to various metric collection systems or services"?

[BlueHatbRit]

Sadly I've just found out the form box doesn't let us put anything extra onto this so I've gone back to "Network daemon for collecting metrics", we only get an extra 2 or 3 characters past that.

[BlueHatbRit]

I've made the suggested changes, if anyone is able to re-review and make sure they're happy then that'd be awesome 😄

[mheffner]

Looks good to me, though I've never submitted one of these before so I'm not sure what level of detail they tend to look for. I assume we can resubmit if they want more clarification or additional info?

[BlueHatbRit]

I'll be honest I have no idea if we can resubmit after, but I'd assume we can so we'll have to ride the boat and see!

[BlueHatbRit]

The application has been submitted for StatsD using the maintainers@statsd.app email address. Hopefully we'll hear back soon 🚀

[BlueHatbRit]

Application id is 1152573 for anyone that wants to keep a watch on it.

[BlueHatbRit]

Sadly the application was declined, they had some specific issues with the application itself but also with the general use case. By the sounds of the response even a resubmission wouldn't really fit the port assignment use case for them. I'll post the specifics when I get back to my computer in a few days but the outlook doesn't look very promising.

[BlueHatbRit]

Below is the body of the email received by the IANA Services Specialist. It explains the reasons the IESG Expert gave for rejecting the application.

Dear Elliot,

The expert has reviewed your application for a port number. He had the following comments:

Because this service is intended to operate internal to a machine, it would not be eligible for an assignment.

This request would also have been declined for any of the following criteria, FYI:

The concern about seeking an assigned port to avoid squatting (unauthorized use of port 8125 by those not assigned it) would not be alleviated by the assignment of a new port. In fact, this application is an example of such squatting in its current use of that port anyway, so it is curious why this application should assume protection against the behavior it itself already exhibits.

Services over UDP are expected to follow the guidelines of RFC8085. This is not consistent with the response to question 2 below.

New services are expected to support security to avoid the need for additional ports in the future for new versions/variants. This is not consistent with the response to question 4 below; it is not sufficient to put the onus on the user to determine whether things run using locally available information not inside the service.

New services are expected to provide security. It is not sufficient to put this responsibility on the user, as per the response to question 6 below.

Finally, if this were to proceed, at best the assignment would only proceed for the currently used port (8125), given it is unassigned. This would not alleviate your concerns and the rationale for this request and so a new assignment would not be productive.

It sounds to me like they're pretty set against assigning a port to statsd's use case, unless anyone interprets this differently and thinks it's worth persuing more, I'll probably look to get the request closed by IANA.

[lzap]

At least you've tried, /cc @natoscott I believe SELinux team will have no problems with assigning port type to statsd. Thanks for info!

[BlueHatbRit]

Thanks @lzap, please do let us know if this does happen, we'd be keen to know 😄

[BlueHatbRit]

Closing as this was rejected by IANA/IESG. Would be great to see if SELinux can assign a port anyway, I'll leave the origina issue #682 open for now.

[lzap]

@BlueHatbRit well it actually happened already in Fedora:

fedora-selinux/selinux-policy@5fa8f7c
fedora-selinux/selinux-policy-contrib@5e590a3

And I asked my colleagues to backport this into RHEL8 line.

https://bugzilla.redhat.com/show_bug.cgi?id=1746511

Thanks!

[saper]

I had a quick look at this and I think it could be salvaged (glad to help) but one thing that really worries me is complete lack of security. Versioning is also problematic.

There is also an interesting problem that this is a one-way protocol and here we specify only the server-side behaviour. In this case it is pretty easy to flood the destination with too much traffic. How do large installations using statsd cope with this, preventing burst traffic hitting a single instance?

[lzap]

In this case it is pretty easy to flood the destination with too much traffic.

Have you tried yourself? In case of UDP there is a buffer and all excessive traffic is simply dropped by the kernel. In case of TCP, the traffic will be slowed down by the protocol as it's guaranteed delivery. I believe statsd protocol/service is not different from pretty much any other service.

But I guess it's the wrong thread for this discussion.

[BlueHatbRit]

I don't have the exact statistics, but I'd wager than 90% of installations use UDP, TCP feels very much like an addition just "because we can". As @lzap said with UDP the traffic is just dropped.

Since StatsD is designed to be run internally and never be exposed to the internet, a lot of the responsibility is on the user to understand the load the spin up a new node as required if they wish to handle the load. If the sys admin wishes to scale up to manage additional load then there are systems out there for autoscaling but that really sits on an infrastructure level rather than with statsd itself.