Subject: [tcpm] TCP port names option ID

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

Hi, all,

In response to some discussion on the IETF 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.

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.

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

---

From: Tim Shepard <[email-masked]>
Date: Sat, 15 Apr 2006 23:21:51 -0400

>From Joe's draft:

>   Portnames need to fit inside the available TCP option space, which 
>   provides 40 bytes for options. It is useful to consider that TCP SYN 
>   packets may include other options consuming up to 33 bytes, notably: 
>
>   o  16 bytes of authentication [Bo05] [We06] [To06] 
>
>   o  4 bytes of MSS 
>
>   o  10 bytes of timestamp 
>
>   o  3 bytes of windowscale 
>
>   This leaves only 7 bytes for the portname option, or 5 bytes for the 
>   NAMESTRING.

I had not thought of the 16 bytes of authentication until I saw it on
the list in the draft.  Ouch.  Can we hope that will be deprecated by
the time something like a service name option gets deployed?

What about the TCP Sack-Permitted Option which is 2 bytes long?  (And
is very common on TCP SYN packets these days.)  If you add that to the
list, we're down to 3 bytes for the NAMESTRING, which is only one byte
more than the 16-bit port number that we started with.

In any case, it seems if we go forward with this, it will be the last
option we can add to the TCP SYN packet without breaking something, as
we will have (in some cases) completely used up all space for a TCP
option.  So before we go forward with this, we should make sure we
really want to do that.

\begin{thinking-out-loud}

Do we need a new "extended TCP options" option?  I cannot think of how
to do that in a backwards compatible way.

When I've thought about how to bring CHAOSNET-style service name
capabilities to TCP, I figured that you'd send the SYN to port zero
with the service name and argv style arguments to the service in the
data portion of the SYN segment (where we would not have this space
crunch), and have the reply come back with the port number filled in.
If the packet comes back with the correct pair of IP addresses and the
right destination port number, but a source port number we've never
heard of, then before dropping the packet, we'd see if any connection
block was in the SYN_SENT state wants it.  If the ACK is acceptable,
it fills in the foreign port number in connection block.  Use of the
timestamp option could also help make sure that there was no ambiguity
in matching up the SYN-ACK with the SYN (though I expect the ACK value
would be good enough if the ISN was well chosen as per RFC1498.)

This is perhaps less backwards compatable (if not implemented on the
other end, you get a RST), but more likely to last through the
centuries without running out of room for something.

And then, what about SCTP?   If TCP needs needs, doesn't SCTP need
this too?  (Or does it already have it?)

\end{thinking-out-loud}

			-Tim Shepard
			 [email-masked]

---

From: Mark Butler <[email-masked]>
Date: Sat, 15 Apr 2006 23:47:29 -0600

>this too?  (Or does it already have it?)
SCTP uses parameterized INIT / INIT ACK chunks for association 
establishment. Each one can be nearly MTU sized before problems start to 
arise.  SCTP already uses 32-bit verification tags to protect against 
the equivalent of SYN floods and other blind attacks, and there is a 
draft for adding encryption quality authentication to SCTP PDUs on a 
controlled basis.  By 'controlled' I mean authentication (AUTH) chunks 
can be added just to packets that contain certain critical control 
information (notably addip). 

As to the issue of whether SCTP would benefit from something like 
service type /  instance selection parameter, the answer is yes. SCTP 
currently uses ports just like TCP, except shared over multiple 
addresses.  Typical implementations normally allocate ports at the host 
level, rather than  IP address level.   A typical outbound connection 
will reserve the selected local port number on all available addresses, 
and extend that reservation to new ones (otherwise ASCONF does not work 
properly). 

 - Mark B.

---

From: Joe Touch <[email-masked]>
Date: Sat, 15 Apr 2006 22:58:26 -0700

> the time something like a service name option gets deployed?

I would prefer that IPsec were used to TCP authentication. That said,
I'd be glad to hear if any of the above can be left out of the SYN in
favor of waiting for the data packet, i.e., other than authentication.

As noted in the ID, though, this is an issue only for a small set of
protocols for which TCP-level auth is currently either deployed or
intended (routing protocols).

> option.  So before we go forward with this, we should make sure we

That argues for rethinking the TCP auth option except for routing
protocols, which is basically where I thought things were anyway.

> to do that in a backwards compatible way.

Why would it need to be backwards compatible? It needs to fail in a
non-silent way - just as this option does, but if space is limited the
initiator might retry with fewer options.

> crunch), and have the reply come back with the port number filled in.

Putting data in the SYN can cause problems - in particular, if the
implementation wants to send an MSS, you need to hold off on some to
create space for the option; the data could be overwritten by subsequent
packets, since it cannot be ACKd' until the connection is open (which
data do you believe?), etc.

> centuries without running out of room for something.

I'm more wary about playing with data space than playing with the option
space; we can always extend the option space in equally non-compatible
ways for the centuries ;-)

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 17 Apr 2006 09:34:16 -0400

> option.  So before we go forward with this, we should make sure we

Or reconsider things like:
http://www.potaroo.net/ietf/all-ids/draft-kohler-tcpm-extopt-00.txt
or
http://www.potaroo.net/ietf/all-ids/draft-eddy-tcp-loo-03.txt

-- 
Wesley M. Eddy
Verizon Federal Network Systems
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Mon, 17 Apr 2006 08:18:30 -0700

> http://www.potaroo.net/ietf/all-ids/draft-eddy-tcp-loo-03.txt

Those might be useful, but as portnames notes, this is an issue ONLY for
SYNs containing the TCP/MD5 or other TCP-level authentication options.

IF we move forward with TCP-level security for anything other than
routing protocols as a stop-gap until IPsec is used, perhaps, but only
in that case, IMO.

Joe

---

From: Ron Bonica <[email-masked]>
Date: Tue, 18 Apr 2006 10:36:11 -0400

Hi Joe,

If you want devices to filter packets based on the TCP Port Name Option,
 you might consider placing that option first in the list TCP options.
That would make it easier to filter in hardware.

                                -r

Joe Touch wrote:
> ----