[e2e] What if there were no well known numbers?
David P. Reed
dpreed at reed.com
Wed Aug 2 19:39:27 PDT 2006
In summary, the security emperor would be exposed to the elements, as
well-known ports are indeed a bad idea, at least in my personal opinion.
In my ancient proposed protocol (which I dropped in favor or helping
build TCP), called DSP, the concept was that an endpoint's name did not
contain a separate "host" boundary. Instead it was the name of a
process port. One could not tell by the endpoint-name structure
whether two named endpoints were on the same machine.
The advantage of endpoint unique-naming was that it increased
"information hiding" and therefore enhanced modularity. The same would
be true if well-known ports were dropped.
The concept of "well-known ports" was built for a world in which there
was no lookup function, no DNS - in fact for a world where people typed
addresses in octal, long before there was a naming service (even before
the hosts file).
Then operating systems API types decided that they should only allow
processes of certain privileges to listen on certain predefined ports.
This would have been unnecessary if all services were offered on
randomly chosen endpoint addresses that were cataloged upon creation in
a DNS-like service.
But you asked what would go wrong. Here's what would break. The
entire Internet security community operates under the assumption that
port numbers have magical, mysterious properties such that one can
"block ports" and achieve perfect security.
In fact, blocking ports achieves no security to speak of. But you'd be
threatening to expose the Emperor's nakedness with this proposal.
John Kristoff wrote:
> Could the removal of well known numbers actually be a rousing change
> more fundamental to the Internet architecture than anything we've seen
> before, even more so than commercialization, Microsoft Windows
> implementation nuances, NATs and multihoming. Indulge me for a momment.
> There is a Internet Draft that has as part of the file name
> "no-more-well-known-ports". The basic idea is that DNS SRV lookups
> should be used to determine a unique port with which to get service
> from the intended destination server.
> In some ways this approach is appealing. I thought it might be a
> nice way to slow the tide of arbitrary protocol port filtering and
> hamper common remote attacks against a particular well known service.
> Looking ahead a bit howver, if this were widely implemented, what
> other outcomes might we see given some time? DNS would become
> increasingly important of course. Maybe even enough for a small
> boom market within that sector. I can envision companies selling
> boxes that "mangle" or proxy SRV responses in the name of some
> defined site policy.
> In short, couldn't this, wouldn't this, lead to a rapid rise in DNS-
> based walled gardens (or if you prefer the quick and steady rise of
> a fractured root, eventual modus operandi) as everyone moves to
> replace their udp/tcp packet manglers with RR-scrubbers?
> Am I way off here?
More information about the end2end-interest