Subject: Re: Guidance needed on well known ports

From: [email-masked] (Noel Chiappa)
Date: Thu, 6 Apr 2006 21:37:49 -0400 (EDT)

> From: Joe Touch <[email-masked]>

    > TCPMUX doesn't 'handoff'. It expects that .. the service desired is
    > served off of its port once opened after the initial exchange
    > (in-band).
    > .. The downside is that it then forces a two-step demultiplexing of
    > incoming packets; there may be utility in a variant that allows the
    > dest port to be unbound and later filled-in, or changed during the
    > connection, so that services can be more efficiently demultiplexed.

I'm missing something here. A TCP connection is identified by the (srcaddr,
sport, dstaddr, dport) tuple. TCB's are looked up by this tuple. Connections
to TCPMUX will all have the same dstaddr/dport, but will presumably have
different srcaddr's, and (presumably) random sport's, and can be
distinguished that way.

Why can't the TCPMUX listener just bind the correct application to the TCB
(after figuring out what the appropriate application is), and then forget
about the connection, leaving it entirely to the application to deal with?
All packets which belong to that connection will automatically go to that
TCB, and thence to the application, with no second layer of demux needed.
Am I missing something?

	Noel

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

---

From: Lyndon Nerenberg <[email-masked]>
Date: Thu, 6 Apr 2006 18:52:33 -0700

> TCB, and thence to the application, with no second layer of demux  

On BSD and Solaris you can just pass the file descriptor from the new  
connection to the already running server.

--lyndon

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 6 Apr 2006 22:50:06 -0400

On Thu,  6 Apr 2006 21:37:49 -0400 (EDT), [email-masked] (Noel

> TCB, and thence to the application, with no second layer of demux needed.
No -- that's precisely how it works.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: Eliot Lear <[email-masked]>
Date: Fri, 07 Apr 2006 08:32:08 +0200

In thinking about this some more if we end up with a TCPMUX like
approach for TCP, how shall UDP,  SCTP, et al be handled?  Is it okay to
handle them differently?

Eliot

---

From: Ned Freed <[email-masked]>
Date: Fri, 07 Apr 2006 08:46:59 -0700 (PDT)

> connection to the already running server.

Similar tricks are possible on most other systems, including Windows and Linux.
The details vary somewhat depending on platform but they are close enough that
basically the same code can be used across most common platforms.

				Ned

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Apr 2006 12:50:51 -0700

Hi,  Noel (et al.),

> about the connection, leaving it entirely to the application to deal with?

There are three ways to proceed:

	1) set the port number after the handshake (as I described)
		i.e., dynamic port negotiation
	2) continue to use the initial port number for packet demuxing
		i.e., portname demuxing
	3) let the port number be fixed, but use the string for the
		service binding

#3 solves the problem of service binding without involving the DNS,
allowing endpoints to determine the meaning of a port (which is where
that meaning is defined anyway)

That's fine, and as others have noted, simpler to implement. The option
would be used only in the SYN, and after that it would be unnecessary
(and ignored if used).

#2 is more complicated, and increases the port space. That's probably
unnecessary at this time.

#1 is more complicated; it's useful where a number of hosts emulate a
single host (e.g., behind a NAT) since it can avoid collisions in
selecting the otherwise arbitrary destination port, but again it's
unnecessary at this time.

So far it looks like only #3 (service binding) will be covered unless
there's a real need for either dynamic port negotiation or portname
demuxing.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Apr 2006 11:54:29 -0700

> approach for TCP, how shall UDP,  SCTP, et al be handled?  Is it okay to

I'm addressing this in the draft (in progress).

UDP can't support the idea; there's no option space.The alternative
would be to reserve a port and assume that bytes after the UDP header
always have the portname, but that seems like a bad idea (interferes
with the separation of header and data supported by DMA, e.g.)

SCTP and DCCP probably can handle a similar option, but that would be
addressed in separate documents.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 14 Apr 2006 15:46:12 -0700

Hi, all,

In response to some discussion on this mailing list, the following ID
has been submitted. It's intended to become a TCPM work item (thus the
header) if there's sufficient interest.

PLEASE TAKE FURTHER DISCUSSION TO THAT LIST ([email-masked])

For the original discussion, see the [email-masked] archives, and look
for "Guidance needed on well known ports".

The draft available at the following URL until it's in the ID repositories:
http://www.isi.edu/touch/pubs/draft-touch-tcp-portnames-00.txt

Joe

- ----

TCPM WG                                                        J. Touch
Internet Draft                                                  USC/ISI
Expires: October 2006                                    April 14, 2006

                        A TCP Option for Port Names
                     draft-touch-tcp-portnames-00.txt
...
Abstract

   This document specifies a new TCP option that specifies services by a
   string name. This option separates the use of port numbers for
   connection demultiplexing from their use as a service identifier. The
   option allows a larger number of concurrent connections for a
   particular service, as well as potentially enabling more explicitly
   coordination of services behind NATs and firewalls. This option
   should be supported in new TCP implementations.