Subject: RE: Port numbers and IPv6 (was: I-D ACTION:draft-klensin-iana-reg-policy-00.txt)

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 15 Jul 2005 11:48:28 -0700

It seems to me that the underlying problem here is that fixed port
numbers is not really the right solution to the protocol identification
problem.

When this was first proposed the number of machines on the Internet was
small and there was no DNS, only the host file.

The port number allocation scheme is really trying to do something that
should be done by the naming infrastructure. This is what SRV is for.
With SRV there is no longer any need for new protocol port assignments.
Protocol designers should be told to apply for an SRV prefix instead.

There are certain limitations to the SRV prefix scheme but these are
entirely fixable. All we actually need is one new RR to allow one level
of indirection to be introduced. With that in place it is possible to
use prefixed SRV records in place of port assignments and prefixed TXT
records as a means of expressing protocol configuration information.

Incidentially with these changes in place the DNS then provides all the
infrastructure that is required to deploy Web Services. UDDI becomes
superfluous. Existing deployed infrastructures such as HTTP and SMTP can
be developed in ways that are architecturally equivalent to the WS-*
approach.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 15 Jul 2005 15:51:54 -0400

> Protocol designers should be told to apply for an SRV prefix instead.

Agree, for the most part.  Fixed port numbers do have some operational 
advantages, though...

---

From: John Kristoff <[email-masked]>
Date: Tue, 19 Jul 2005 09:23:36 -0500

On Fri, 15 Jul 2005 11:48:28 -0700
"Hallam-Baker, Phillip" <[email-masked]> wrote:

> entirely fixable. All we actually need is one new RR to allow one
> level of indirection to be introduced. With that in place it is
> possible to use prefixed SRV records in place of port assignments and
> prefixed TXT records as a means of expressing protocol configuration
> information.

I'm concerned this may usher in DNS SRV message filtering in addition
to protocol port filtering.  One way of addressing that potential
effect is to make the port assignments be negotiated between two
communicating end hosts.  This could be used with or without DNS.  It
might also provide some remote attack protection, since only a simple
passive listener is used to perform the local/remote address/port
selection for any active client before the real communication switches
to agreed upon (and bound only to) the two process end points.

John

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 19 Jul 2005 16:36:05 +0200

On Tue, 2005-07-19 at 09:23 -0500, John Kristoff wrote:
> to protocol port filtering.

Filtering can always be done, that is the right of the network
administrator doing the filtering. That some users won't like it is
indeed an issue, but that is political and not technical.

> One way of addressing that potential

As previously mentioned, RFC1078 - TCPMUX:
 http://www.ietf.org/rfc/rfc1078.txt

Greets,
 Jeroen

---

From: Keith Moore <[email-masked]>
Date: Tue, 19 Jul 2005 20:25:20 +0200

> indeed an issue, but that is political and not technical.

Thinking of this as a "right" is the wrong way to think about it.  A 
more relevant question is whether this works well.  There are a number 
of problems associated with interception proxies, many related to a lack 
of accountability and transparency, others related to compromises in 
end-to-end security.

I also disagree that the network admen inherently has a right to 
interfere in arbitrary ways with communications between parties using 
his network- there are cases where this "right" may exist but it is 
because of some other role of the network operator - not merely because 
he is operating a network.  Does a postal or courier service have the 
"right" to open, alter, and reseal paper messages?  Does a telephone 
company have the "right" to alter conversations?  The job of the network 
is to carry messages transparently; and applications need to be able to 
assume that the network is behaving in a simple, predictable, and 
reasonably uniform manner independent of the locations of the hosts that 
are participating.

Host and application security are not the job of the network.  At best, 
the network can cooperate with hosts and applications to enhance the 
security that the hosts and applications already provide.  But when the 
network tries to provide security independently of host and application 
policy, the result is usually degraded interoperability and rarely good 
security.

Keith