[e2e] Port numbers, SRV records or...?

[Dave Crocker]

Folks,

John Kristoff wrote:
> Could the removal of well known numbers actually be a rousing change
> more fundamental to the Internet architecture ...
>
>...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.  ...
> 
> 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?


The thread seems to have veered off, into an interesting discussion of history.
 There were a few responses to the main line of your query, and I am hoping we
can consider it more extensively.

In what follows, I decided to make straight assertions, mostly to try to
engender focused responses.  I also decided to wander around the topic, a bit,
to see what might resonate...

At every layer of a protocol architecture, there is a means of distinguishing
services at the next layer up.  Without having done an exhaustive study, I will
nonetheless assert that there is always a field at the current layer, for
identifying among the entities at the next layer up.

That field always has at least one standard, fixed value.  Whether it has more
than one is the interesting question, and depends on how the standard value(s)
get used.  (If there is only one, then it will be used as a dynamic redirector.)

The questions of how and where the information is encoded both strike me as
completely irrelevant, for any basic discussion about the topic you raise.  The
questions are obviously essential for matters of packet parsing and possibly for
some aspects of scaling, but irrelevant to any sort of information theoretic
perspective.  Whether the bits are interpreted as a number or an ascii string
does not matter.  Whether the field in distinct or part of some other
"addressing" field also does not matter. They well might be extremely important
for human administration and/or encoding efficiency, but not for basic
capabilities.

(Caveat:  XNS had the equivalent of the port number be part of the network
address and this had an impact of what information its routers used.  It took
some years before developers decided to have IP routers started paying attention
to port number...)

What *does* matter is how to know what values to use. This, in turn, creates a
bootstrapping/startup task.  I believe the deciding factor in solving that task
is when the binding is done to particular values.  Later binding gives more
flexibility -- and possibly better scaling and easier administration -- but at
the cost of additional mechanism and -- probably always -- complexity, extra
round-trips and/or reliability.

Which is better, polling or interrupts?  The answer, of course, is that it
depends.  It depends on the number of participants -- both total possible and
currently active -- and their activity pattern.  Similarly, the choice between
relatively static, pre-registration versus dynamic assignment depends upon how
many services are involved and how quickly things change.  (Hmmm.  Dynamic
assignment requires pre-registration too...)

In discussing the differences between email and instant messaging, I came to
believe that we need to make a distinction between "protocol" and "service".
The same protocol can be used for very different services, according to how it
is implemented at operated.  Some folks will remember that in the 70's, email
had an instant messaging function.  While it involved a different FTP command
than what we call email, the protocol was otherwise identical. Today, the
service distinctions are immediacy and reliability.  That is, email is reliable
push, except that delivery is into a mailbox rather than the screen, thereby
making the last hop be "pull". This creates the view that email is not
immediate. But it *is* reliable, in that a message survives most crashes by the
host holding the message.  IM is push all the way, but a message does not
survive a crash.  My point, here, is that these are implementation and operation
distinctions, rather than inherent differences in the exchange protocols.

If a "protocol" does not automatically define a "service" then what does?  In
the world of ports, it is the port number.  In the world of SRVs, it is the SRV.
Either way, they permit repurposing a protocol for different uses.

Observation:  Our specifications usually fail to make the distinction between
protocol and service, either by conflating them or by ignoring the latter.  I
suspect we regularly get into trouble because of this.  At the least, we tend to
carry implicit assumptions about the service that fail to consider likely evolution.

So...

To say "What if there were no well known numbers" we cannot mean "What if there
were no initialization rendezvous mechanism?"

I'll suggest that the question is really "What are the requirements for such a
mechanism that might be better than our current model?"

Are we seriously interested in trying to "trick" firewalls, by eliminating
predictable service identifiers?  Do we think that will really work?  Do we
really need to solve this "problem"?

Are there scaling, reliability or performance issues that suggest problems with
the current problem?

Eliot's lear-iana-no-more-well-known-ports seems to focus on the problem that we
have a large number of unused and/or defunct well-known ports and that using SRV
would be better.  While it is certainly true that the SRV name space is much
larger, it is also true that the performance, complexity and reliability
differences in using SRVs are massive.

In other words, what problem do we have or do we anticipate?

When we have some sense of that, we can consider how to solve it.

d/
-- 

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net