
Port Squatting - sciurus
http://queue.acm.org/detail.cfm?id=2674602
======
kragen
SRV records, used in DNS-SD and notably in Zeroconf, provide you the port
numbers dynamically. Assigning port numbers to internet services globally
across the entire internet was a mistake, and one that we can avoid for newly
defined services. It creates two problems:

1\. The one mentioned in this article: the namespace is finite and small,
leading to conflicts over the administration of its allocation;

2\. virtual hosting — you can only have one instance of a service per IP
address, unless you kludge into the higher-layer protocol ( _every_ higher-
layer protocol) some way of telling the server which instance of the service
you were _trying_ to connect to. And even then, all your “virtual hosts” have
to be running on the same software — you can’t run some of them on Courier
IMAP and others on Dovecot, say. By contrast, if you just bind them to
different ports and publish those port numbers in DNS SRV records, these
problems go away.

TCPMUX on port 1 was the first attempt to solve this problem, but it didn't
catch on. DNS-SD/Zeroconf/Bonjour/Rendezvous/SRV records seem like a viable
and highly usable alternative, as long as we don’t get lost in the alphabet
soup.

~~~
JoshTriplett
I agree entirely. You'd still have a string namespace, but that string
namespace is more easily subdivided.

One key downside, though: for a conversation with any service not in your
cache, you need to resolve the service before connecting, rather than knowing
in advance. So there's still an advantage to any service that can use a well-
known port. That advantage partly goes away if you can resolve a hostname in
the same DNS request as a service on that host, but that would require
improving the current level of integration between clients and system
resolvers.

~~~
kragen
Really? I didn’t realize there was a client-side problem there. I guess
there’s still a _security_ problem, though, if the SRV record points to a
hostname that nameserver may not be authoritative for.

Edited to be more specific: I mean, if you want to cut the time to resolve a
service name to an IP:port pair from two round-trip times down to one, then
you need to get the A or AAAA record from the same nameserver as the SRV
record. Getting the nameserver to include that record in the “additional”
section, like a glue record for NS delegations, isn’t hard; but if it’s in
another gTLD, how does the client know that nameserver is authoritative for
that domain? It could be sending you a false A record. You wouldn’t want to
cache that; it could enable a MITM attack! Better check with the gTLD servers.
But that means another round-trip-time delay.

~~~
kelnos
_It could be sending you a false A record. You wouldn’t want to cache that; it
could enable a MITM attack! Better check with the gTLD servers. But that means
another round-trip-time delay._

If the nameserver you're connecting to is doing things like that, this is a
problem for _all_ your traffic, not just traffic that relies on SRV records.

~~~
kragen
This is not necessarily the nameserver local to you; this may be the
nameserver that’s authoritative for the SRV record you’re trying to look up.
Maybe you’re trying to talk to a machine in North Korea.

------
jacquesm
One absolutely excellent reason for not tying services to port numbers is that
it instantly undoes a large amount of strangling currently done to the peer-
to-peer nature of the net. If you could run a web server with a url sans
:port/ combo on any port that you wanted to then ISPs would have no easy way
of blocking access to your self-hosted service without doing deep packet
inspection.

It's totally ridiculous that with 100 Mbps 'down' and 20 Mbps 'up' you still
need a hosting account for a small web server.

~~~
viraptor
On the other hand, for home users mapping services to ports statically makes
it easier to apply QoS at the router. But when ports are randomised, or
shared, it's hard to do anything about it.

For example on a rather high-end netgear home router I can apply QoS by port,
but that means Crashplan, Web and Skype use the same port. Even though I'd
like them to be low, medium and high priority respectively.

------
exabrial
Port numbers as the next ipv4 "problem", oooh I like it. No amount of garbage
collection for careful allocation will solve it. Expect another heavy-handed,
non-memorizable, rear-ward-looking solution from the IETF that involves
reimplementing the whole Internet.

Oh, SRV records, right that's what I was going to post about. Yes, once again,
SRV records would have solved this problem in quite an elegant and simple way.
And it's backwards compatible until we hit an actual port number crisis...
cool!

~~~
jsprogrammer
The article claims 90% of the space is still available.

~~~
wongarsu
Because nobody actually registers their ports. It's a multi-month process with
little benefit to anyone.

~~~
vacri
And even then, it doesn't matter because it's still simply convention. The
internet won't break for anyone if I serve something other than mysql on port
3306. There's only a few port numbers where the public edifice around them is
so huge that they really can't be that mobile - web (two ports), mail (six or
so), dns (one port) and so forth.

------
ams6110
Unlike IP addresses, port numbers are only conventions, they are not
technically required to be unique.

If I want to run an ssh server on port 80 (HTTP) then I can, and it will work
just fine, and it won't bother anyone else.

~~~
wise_young_man
In addition, you might want to run a process on a non standard port for
security through obscurity such as not running SSH on port 22.

~~~
notfoss
Yes, because if nothing else, it almost eliminates failed login log messages
(talking specifically about ssh here).

~~~
tracker1
true enough... the fail2ban messages are bad enough without running SSH on
port 22... on the flip side, it sucks in other ways if you want to use SSH for
something that isn't complete host access (terminal based BBS for instance).

