Subject: [tcpm] TCPx2

From: Mark Allman <[email-masked]>
Date: Mon, 08 May 2006 12:05:26 -0400

Hi folks!

I jotted out an i-d on an idea that has been rolling around my head for
a while.  I submitted it, but until it pops out in the archive you can
slurp a copy here:
http://www.icir.org/mallman/draft-allman-tcpx2-hack-00.txt.  The general
idea of this hack is to increase TCP's header size once to deal with
these field-foo-is-not-big-enough issues rather than trying to design
a solution for each of these.

(As the document says, this is not a proposal for a TCPng.)

So, crack open an adult beverage, take a look and let me know what you
think ... or, at least enjoy the read! :)

allman

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

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 8 May 2006 13:28:52 -0400

> think ... or, at least enjoy the read! :)

What would the NAT considerations be for either this or a TCPng?  Or, what
would be the most appropriate goals with regard to the installed base of
NATs?

IMHO, this is the primary consideration before examining any modified
header format.

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

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 8 May 2006 10:49:14 -0700

Increase size fields is definitely a good reason for looking at TCPx2.
After all, the current land-speed record is about 8 Gbps, and we have to
support distances of at least 1/2 grand circle of the earth, i.e. 20,000
km, i.e. about 100 ms one way, 200 ms RTT. At that speed, there are
200MB of data in transit. Allow a few revs of Moore's law, and pretty
soon bandwidth delay products exceed 4GB, i.e. have a serious problem
with 32 bit sequence numbers.

But there are other reasons as well, e.g.:

1) To get rid of the SYN flooding attack, it would be nice to start with
a 4 ways handshake rather than the current 3-ways handshake.

2) It would be nice to make TCPx2 sessions independent of IP addresses,
so the session can survive if the host moves to a new address, or if a
multi-homed host starts using a new address.

3) It would be nice if TCPx2 allowed an initial exchange over a
secondary channel (e.g. in a SIP payload), so as to facilitate NAT and
firewall traversal.

4) If would be nice if the initial exchange included the negotiation of
a session key, so the traffic could be encrypted and/or authenticated,
much like with the current MD5 option.

-- Christian Huitema 

> -----Original Message-----
> From: Wesley Eddy [mailto:[email-masked]]
> Sent: Monday, May 08, 2006 10:29 AM
> To: Mark Allman
> Cc: [email-masked]
> Subject: Re: [tcpm] TCPx2
>

---

From: "Armando L. Caro, Jr." <[email-masked]>
Date: Mon, 08 May 2006 14:04:50 -0400

Mark,

I have one initial thought in reference to the transition section of the
draft. Instead of sending TCPx2 and TCP syn packets sequentially,
sending them in parallel would reduce handshake latency for legacy TCP
systems. If the receiver only supports TCP or TCPx2, only a single syn
is acked. If the receiver supports TCPx2, then it interprets both syns
as the same connection setup request and merges the two (I'll explain
below). The underlying assumption is that the 32-bit port number has to
be mappable to a 16-bit port number, but this is already implicitly
assumed in the draft's transition solution. A true 32-bit port number
(ie, larger than 2^16-1) can only be used when the client knows that the
server supports TCPx2.

The parallel SYN idea is as follows.

Client C and Server S support TCPx2 (and TCP).

Scenario A
1. C sends a TCPx2 and TCP syn packet in parallel to S

2. S receives TCPx2 syn packet first, and it is syn/acked immediately.

3. S receives TCP syn packet, and recognizes that it maps to the TCPx2
  syn received, so the TCP syn is silently discarded.

4. TCPx2 connection setup continues as normal.

Scenario B
1. C sends a TCPx2 and TCP syn packet in parallel to S

2. S receives TCP syn packet first, and it is syn/acked immediately.

3. S receives TCPx2 syn packet, and recognizes that it maps to the TCP
syn received. S syn/acks the TCPx2 packet, essentially tell C that S
does support TCPx2, so migrate connection from TCP to TCPx2.

4. C receives TCP syn/ack, and proceeds as normal.

5. C receives TCPx2 syn/ack, and realizes that S does support TCPx2. It
basically upgrades the TCP conection to a TCPx2 connection, and sends an
TCPx2 ack to complete the TCPx2 3-way handshake. Since the only
difference between TCP and TCPx2 are the header fields, upgrading should
be easy for an endpoint.

6. S receives TCPx2 ack to complete the TCPx2 3-way handshake, which
triggers it to upgrade its end of the TCP connection to TCPx2.

Note: If the TCPx2 syn/ack from S to C gets lost, S will retransmit it
after a timeout. Also, each TCP packet received by S from C can trigger
a new TCPx2 connection establishment for migrating the existing TCP
connection to the upgraded version.

-- 
Armando
www.armandocaro.net

---

From: Frank Kastenholz <[email-masked]>
Date: Mon, 08 May 2006 14:15:09 -0400

Christian
there are probably a couple of other things that
one might wish to do in tcp if one were to allow
the protocol (in the sense of algorithms, functions,
and so on) to be changed. I can think of one or two
myself (how about a different checksum, especially
for jumbograms?)

f

---

From: Frank Kastenholz <[email-masked]>
Date: Mon, 08 May 2006 14:24:04 -0400

why build the state?
why not just put an option in the tcp syn that says 
'answer back in tcpx2, if you'd like'

f

---

From: "Armando L. Caro, Jr." <[email-masked]>
Date: Mon, 08 May 2006 14:27:52 -0400

Ah, but now we are going down the path of an entirely different
protocol. Mark's intention was to keep the protocol semantics the same,
but just get more header space.

-- 
Armando
www.armandocaro.net

---

From: Mark Allman <[email-masked]>
Date: Mon, 08 May 2006 14:43:22 -0400

> What would the NAT considerations be for either this or a TCPng?  Or,
> what would be the most appropriate goals with regard to the installed
> base of NATs?
> 

I think NATs are going to kill any new TCPng or TCPx2.  I don't think
there is any question about it.  I also envision that in either case the
changes to make NATs grok the new protocols will be pretty easy.  And,
the transition issues in the current draft are aimed at just this sort
of thing.  I.e., a TCPx2 can fall back to TCP.

allman

---

From: "Armando L. Caro, Jr." <[email-masked]>
Date: Mon, 08 May 2006 15:07:14 -0400

> 'answer back in tcpx2, if you'd like'

Good point. That makes more sense.

-- 
Armando
www.armandocaro.net

---

From: Ignacio Goyret <[email-masked]>
Date: Mon, 08 May 2006 12:09:38 -0700

>Good point. That makes more sense.

Except you would lose access to the 32-bit source port number.

---

From: Mark Allman <[email-masked]>
Date: Mon, 08 May 2006 15:13:34 -0400

> Except you would lose access to the 32-bit source port number.

Right.  Not to mention the larger option space on the SYN - which is
when it most crowded (if you buy that it's crowded at all).

I had thought of the parallel thing (but, not worked it out as much as
Armando did - I'll have to think on it a bit more).  Doing it in
parallel does not offend me on the surface.

allman

---

From: Frank Kastenholz <[email-masked]>
Date: Mon, 08 May 2006 15:24:42 -0400

At 03:13 PM 5/8/2006, Mark Allman wrote:

>Right.

carry the appropriate header fields
in the option. you could do it with
64 bits -- 32 for each of the sport and dport.

(requires defining that when synning a connection,
all 64bit sequence numbers start with the high32
bits 0.)

f

>  Not to mention the larger option space on the SYN - which is

---

From: "Armando L. Caro, Jr." <[email-masked]>
Date: Mon, 08 May 2006 15:25:30 -0400

> Except you would lose access to the 32-bit source port number.

It could be part of the option field, but also as I pointed out... if a
client wants to use a port number larger than 2^16-1, then the client
has to KNOW that the server supports TCPx2. You can't map 32-bits into
16. ...so when the 32-bit port number is needed, the client will start
off by talking TCPx2. Legacy TCP cannot be used.

-- 
Armando
www.armandocaro.net

---

From: Mark Allman <[email-masked]>
Date: Mon, 08 May 2006 15:31:05 -0400

> all 64bit sequence numbers start with the high32

You're making more crud than you're saving here.

  * You'd now have to shove all options for TCP and TCPx2 into the
    option space of TCP (40 bytes).  I.e., you better advertise a WS and
    a TS in case you can't use x2.  And, you better advertise bigger
    ports and alternate checksum and ... whatever else we invent in case
    the peer does not support x2.  Things may get tight quick.

  * Your testing the path at least as much as the end host with the x2
    SYN.  The end hosts may support x2 just fine, but if the firewall or
    the NAT doesn't then you're hosed and then you're going to negotiate
    x2 and then have to somehow fall back to TCP---which is the exact
    problem you're trying to avoid by sending only one SYN.

allman

---

From: Tim Shepard <[email-masked]>
Date: Mon, 08 May 2006 18:03:39 -0400

> 'answer back in tcpx2, if you'd like'

While some Firewall/Nat/Middlebox may have let the tcp SYN with
I-can-do-tcpx2-also option through, a tcpx2 SYN ACK packet going back
might not make it (because some firewall or NAT is unaware of tcpx2).

Middleboxes sure do make things fun.

			-Tim Shepard
			 [email-masked]

---

From: Mark Allman <[email-masked]>
Date: Mon, 08 May 2006 23:21:19 -0400

> Middleboxes sure do make things fun.

I'd put it this way .... 

In 2006 it is just as important to probe the network to see whether the
path supports some new protocol as it is to assess whether the remote
peer supports the given protocol.

For me, that means you just have to bite the bullet and send a real x2
packet.

allman

---

From: Mark Allman <[email-masked]>
Date: Tue, 09 May 2006 08:44:31 -0400

> The parallel SYN idea is as follows.

I understand your idea.  I am not sure if I am ready to head quite down
the path you are suggesting, however.

First, it feels a bit gratuitous to fire two SYNs at once.  At least we
could caveat it by saying that a host should cache the peers ability to
do TCPx2.  But, even so, it sort of feels gratuitous to me.

But,

> triggers it to upgrade its end of the TCP connection to TCPx2.

This upgrading business is not sitting right in my head, I guess.  Let
me try an example.  Let's say that TCPx2 has enough option space that we
use some sort of spiffy authentication system for the connection [%].
But, TCP doesn't have enough option space and/or we don't want to burn a
huge fraction of it on authentication because that will push out other
options.  So, we send TCP and TCPx2 SYNs as appropriate, get back a TCP
SYN+ACK and fire an initial window of data.  Now, we get the TCPx2
SYN+ACK and want to "upgrade".  But, now we have already sent the first
bits of the data unauthenticated.  It seems like the stream ought to
either be authenticated or not.

Let me try this way of putting it .... I am not sure that your scheme
always leaves the two ends of the connection "synchronized".

If you added a small SYN+ACK collection delay (in the case when the TCP
SYN+ACK arrives before the TCPx2 SYN+ACK arrives) then we could maybe
just forget upgrades.  But, it seems to me that this is roughly similar
to just sending an x2 SYN first and then a bit later sending TCP SYN.

allman

---

From: Frank Kastenholz <[email-masked]>
Date: Tue, 09 May 2006 16:59:34 -0400

so i was thinking more about the tcpx2 idea
and trying to make my notion of putting an option
in the tcp(x1?) packet to make connection setup and
x2-detection faster, etc etc.

but it seems to me that the real problem is middleboxes
_and_ the fact that routes can change in the network.

suppose that, through any of the methods discussed, a
tcp-x2 connection has been set up between A and B. 
For the sake of argument, suppose that the connection goes
through some middlebox, M1 and that box understands tcpx2
and Does The Right Thing.  Then the routes in the network
change. the connection now goes through middlebox M2
(either instead of, or in addition to M1, it doesn't matter).
And M2 is tcp-x2-challenged, so it zorches the tcpx2 packets...
in other words, tcpx2 connections could suddenly go-away
if/when it pleases the routing-and-middle-box-gods...

(since tcpx2 calls itself a hack, here's a hack of a hack,
cary tcpx2 in udp... it ought to be less likely to hit
a  middlebox that gets upset...)

f

---

From: Joe Touch <[email-masked]>
Date: Tue, 09 May 2006 16:43:31 -0700

I generally like this idea.

I would like to REQUIRE a version number somewhere in here (preferably
up front!), so that *when* we redefine the TCP header we don't need yet
another protocol ID at the IP layer to indicate it.

Joe

Mark Allman wrote:
> ------------------------------------------------------------------------
>

---

From: Mark Allman <[email-masked]>
Date: Tue, 09 May 2006 21:54:25 -0400

> if/when it pleases the routing-and-middle-box-gods...

Maybe I don't quite understand what I am supposed to take away from this
thinking.  I agree that this could happen.  But, it's not like TCP(x1)
is somehow invulnerable to this.  If M1 and M2 are firewalls with
different policies or they are stateful then a TCP(x1) connection could
just as easily get zorched [*].  

My mental model (for whatever that is worth) is that the sorts of
middleboxes that would kill TCPx2 would be pretty close to the edge and
not really particularly susceptible to routing changes.  I.e., all the
packets go through the enterprise firewall, no matter which path they
arrived on.  Or, all packets go through some NAT.  Or, whatever.  If
AT&T has a route change and my packets go a different way they still end
up at the firewall or the NAT.  So, while I agree that the scenario you
played out can happen, I am not sure I am all that compelled that it's a
big deal.  Should I be?

> a  middlebox that gets upset...)

I don't see how this helps.

allman

[*] Nice word!

---

From: Frank Kastenholz <[email-masked]>
Date: Wed, 10 May 2006 09:37:12 -0400

>just as easily get zorched [*].  

I'm not sure either.
That said, I do think that the odds of losing a connection
because of a routing change would be much higher if
the connection was using TCPx2 than if using x1 (though
I can't prove it).

Obviously, if M1/M2 are stateful middleboxes, there
would be a probelm, even if M1 and M2 support the
tcp-flavor-du-jour (assuming that the state is not soft
or that M1 and M2 are not conspiring in some way).

I think that the most likely failure mode would be
that the routes change, the packets go through a new AS, and
that new AS has different policies as to what they do and
do not let into/through their network. This is most likely
not a problem with TCPx1 -- ISPs, etc, do not usually
filter transit/etc traffic based on TCP port numbers or
the like -- but they might/do filter based on IP protocol
number... (hence, my "stick it in UDP" comment).

Policies, software revisions, and so on at the edges of
the ultimate destination are probably less of an issue.
Yes, many companies, etc, are multihomed for reliability,
but often what happens is that both of their net-facing
connections come in to an "unprotected" net which is
connected to the internal nets via firewall/nat/...

>So, while I agree that the scenario you

If TCPx2 is a good idea/etc, then I think that this
really comes down to a deployment/migration/transition
issue, the same as with IPv4/6. I would suggest that
(again, if this goes forward) that there be some
documentation that says "these are the issues that
could occur in deployment/migration... be aware, etc, etc"

I do _not_ think it's a reason to give up on tcpx2.

>I don't see how this helps.

One of the filter-terms that occurs is something
along the lines of
  switch (ip-protocol)
  case tcp: allow
  case udp: allow
  case some-other-known-ip-protocols: allow
  default: drop
the idea is that if the administrators of the network do
not know what the ip-protocol is, it must be an attack or
security problem, etc, so it should be dropped...

so _if_ tcpx2 was carried in udp, it would more likely
be allowed through (the assumption is that the
udp case in the example does not further go and
look at port numbers... which it may well do... sigh)

>[*] Nice word!

i wish i could take credit :-)

f

---

From: "Armando L. Caro, Jr." <[email-masked]>
Date: Wed, 10 May 2006 09:51:34 -0400

> the path you are suggesting, however.
<snip>
> always leaves the two ends of the connection "synchronized".

Well the TCPx2 endpoints would require more state. The initial window of
data will be acked as TCP (not TCPx2) data. Even the though the sender
has upgraded to TCPx2, it knows that the first window of data was sent
with TCP, and thus accepts the acks for the initial window only.

I admit it seems to be getting messy, but I don't think it's all that
bad. The main problem I see is security. It may become easy to hijack a
connection.

> just forget upgrades.

Yes, that might be a useful enough solution.

> But, it seems to me that this is roughly similar

Yes, similar... but not the same as waiting for the TCPx2 syn to timeout
before sending a TCP syn.

-- 
Armando
www.armandocaro.net

---

From: Mark Allman <[email-masked]>
Date: Wed, 10 May 2006 10:11:45 -0400

> number... (hence, my "stick it in UDP" comment).

I guess my mental model is that transit traffic is not filtered like
this.  So, my intuition is that this is all theoretical.  But, I have no
data.  I wonder if any of the SCTP or DCCP folk have experience with
running tests across the Internet that were impacted by filtering that
was not near the edge.

allman

---

From: "Andrew Yourtchenko" <[email-masked]>
Date: Wed, 10 May 2006 16:35:08 +0200

> look at port numbers... which it may well do... sigh)

...And then you have the NAT middleboxes coming into the picture and
it will become quite a fun to make this work reliably, taking into the
account the simultaneous open scenario as well. (Essentially you'd be
creating an overlay - but then why not simply create an overlay and do
IPv6 over it - that's something that is already there)

Now I put my aluminium hat on (just in case) and continue writing...

If going the road of hacks, why not just grab the special case of
srcport=dstport=0   from the TCPx1 (32 bits wasted - tunneling over
UDP wastes 64 bits, right ?), and reuse the remaining fields in the
TCP header, keeping some of the data (TCP flags) in the same place,
and adding the other ones  ?

This would provide a very clear special-case for the middleboxes and
the end hosts, and allow some of the existing features (e.g. ACLs with
TCP flags) to immediately work on a rudimentary scale (controlling the
inbound/outboud x2 overall access).

Since there's technically no new protocol being defined, to me this
kind of hack looks like something possible - it looks like the most
evolutionary hack of the ones at hand. (But I still keep my aluminium
hat on for a while :-)

thanks,
andrew

---

From: Mark Allman <[email-masked]>
Date: Wed, 10 May 2006 11:16:32 -0400

> it will become quite a fun to make this work reliably, 

I doubt it.  But, let's step back for a moment...

(1) This problem is for routing changes in the middle of a connection
    causing a connection to be lost.  That's a very narrow box.  

    (a) Routing is stable on the timescales of most connections.  I.e.,
        it would be quite rare that packets would even travel along two
        paths, let alone be impacted by that change.

    (b) It's not clear that a change in routing in the middle of the
        network is going to represent a change in policy with regards to
        which IP protocol numbers are passed and which are not.  The
        middleboxes that matter are highly likely to be near the
        endpoints.

(2) Are we really saying that in 2006 that one of our engineering
    constraints is that the IP protocol number must be 6 or 17 in order
    to sneak by the middleboxes?  

(3) It's not like this hack of srcport=dstport=0 solves the problem of
    middleboxes with regards to TCPx2.  NATs still have to understand
    the structure of the header such that all connections aren't muxed
    together into a big mess.  Firewalls still have to figure out where
    the port number is to enforce policy (I somehow doubt they'll just
    pass all port 0 traffic).

(4) TCP connections can get toasted today.  The network can go down.
    The routing can start looping.  The remote host can crash or the
    application go away.  I am fine with saying that TCPx2 + routing
    changes + policy changes can be another way that a TCP connection
    can get toasted.  But, let's not make it a bigger deal than it is.

allman

---

From: Tim Shepard <[email-masked]>
Date: Wed, 10 May 2006 11:48:16 -0400

It seems to me that perhaps keeping the initial connection setup
the same with TCP is a good plan.

To give us breathing room, there are two things that I like:

One would be a "I am modern and clueful, and hope you are too
(IAMACAHYAT)."  option that can be sent on the initial SYN and
the SYN/ACK.  Once this option has been exchanged (with the
SackOK and Timestamp and windowscale which also go on the initial
SYN, then more interesting and elaborate things can be negotiated
on the fly with TCP options in later round trips.

Whenever I go looking for space in the TCP header, I keep
noticing the 16 bits of urgent pointer.

And in my fantasies for using contact names instead of port
numbers, I want to find some way to pass an argv-like array of
strings in the initial SYN.

I've also at various times wanted an option on the initial TCP
SYN that says:

 1. "I can migrate this TCP connection to SCTP if you like."

 2. "I would like to establish shim6 state for this."

 3. "I'd like to do HIP with you, can you do HIP?"
      (which would be an implied HIP I1 message)

What would be the general mechanism that we can squeeze into the
exiting remaining TCP option space that will enable us to do the
right thing 5 to 10 years from now when we figure out what the
right thing is, and then when we figure out what the next right
thing is 15 to 20 years from now, do that too, all without
running out of space in the option space on the initial TCP SYN?

I also wonder if we should be thinking about an SCTP migration
plan (where applications that think they are doing TCP are
actually being carried by SCTP in TCP-emulation mode).  I can
imagine that getting to a future (in say 20 years) in which TCP
was strictly legacy might be a good thing.

			-Tim Shepard
			 [email-masked]

---

From: Tim Shepard <[email-masked]>
Date: Wed, 10 May 2006 12:06:17 -0400

> srcport=dstport=0   from the TCPx1 (32 bits wasted - tunneling over

I've been thinking that dstport==0 should mean something special,
where the receiver of such a packet looks in the data for the
information about what service is being contacted, and assigns a port
number and the SYN/ACK comes back with the srcport filled in by
whatever the responder wishes to have in there for demultiplexing
purposes.

If there's a "Full cone NAT" or a "Restricted cone NAT" in the
middle it should work just fine (since the packet coming back has a
dstport that the NAT assigned).

dstport==0 could also convey an implied "I am modern and clueful and
hope you are too. (IAMACAHYAT)" option.

			-Tim Shepard
			 [email-masked]

---

From: "Andrew Yourtchenko" <[email-masked]>
Date: Wed, 10 May 2006 18:12:41 +0200

>         middleboxes that matter are highly likely to be near the

....And in the end of the day it is the responsibility of those
designing that part of the network where the routing change would
occur - I'd expect it to be within the same administrative domain. If
a routing flip causes the alteration of the active security policy
applied to the traffic - there's very probably something to fix even
without the x2.

>     to sneak by the middleboxes?

No. I just enclosed this hack to oppose the tunneling over UDP :-)

>     pass all port 0 traffic).

Absolutely. But again it was mostly just a counter-example vs.
tunneling over UDP  - both approaches share pretty much the same
drawbacks. If we were to do the sneaky tunneling, I think that
sneakily tunneling IPv6 and doing all the rest cleanly on top of it is
a better approach.

Or do it "openly" within the new protocol as you suggest. I was not
against the new protocol number - but rather was sceptical about doing
the tunneling over the UDP.

Sorry I did not state it clearer.

thanks,
andrew

---

From: Joe Touch <[email-masked]>
Date: Wed, 10 May 2006 08:10:09 -0700

Andrew Yourtchenko wrote:
...
> and adding the other ones  ?

Port numbers are reserved by IANA only insofar as they have global,
shared meaning. Between any two hosts - which is ultimately the only
place they really mean anything - they can be defined in any way
mutually agreed.

First, srcport=0 is consistent with IANA use anyway, so that's not
needed. But dstport=0 is just not reserved; it can be used by existing
services at the discretion of the endpoints anyway.

Redefining the ports redefines the service within TCP; it cannot
redefine the header. That would take a version field - as I suggested
yesterday - which has (sadly) always been lacking in TCP (and UDP).

Finally, any flag or field that redefines the behavior of middleboxes is
equivalent from a deployment perspective; they require middlebox
reprogramming to work. Once reprogramming is required, we're debating
lines of code, and I don't think it matters much whether we're parsing
the header for oddly placed fields or double-length fields at that point.

There may be easier ways to extend the TCP header if all we want is
option space. The need for more portspace isn't convincingly motiviated
yet - if for security, it's thin at best. If for increased numbers of
concurrent connections, showing a need would be useful.

In summary, this seems like a fine experiment, but so would a simpler
mod that just extended the option space. The latter might end up being
preferable w.r.t. middleboxes, aren't options are typically ignored by
middleboxes anyway?

Joe

---

From: "Armando L. Caro, Jr." <[email-masked]>
Date: Wed, 10 May 2006 12:20:01 -0400

> running out of space in the option space on the initial TCP SYN?

I think you are proposing a good problem to be solved...
I think you're initial idea is basically that TCP eventually evolves
into a protocol to negotiate which protocol to use. Right?

> actually being carried by SCTP in TCP-emulation mode).

Ryan Bickhart developed a shim that does do this, but it doesn't
negotiate options... it does basically the same thing Mark originally
suggested for TCPx2. Start by trying to initiate a SCTP connection, if
no response, then try TCP. The shim allows the endpoints to use SCTP
even if the app only knows TCP. No app code modification required.

http://www.cis.udel.edu/~amer/PEL/poc/pdf/BickhartMSthesis.pdf

> I can

But I think you're initial idea is basically that TCP eventually evolves
into a protocol that is only used to negotiate which protocol to
actually use for data transfer.

-- 
Armando
www.armandocaro.net

---

From: Joe Touch <[email-masked]>
Date: Wed, 10 May 2006 09:53:40 -0700

> whatever the responder wishes to have in there for demultiplexing

TCPMUX (on dstport==1) puts the service name in the data portion; the
trouble with that is described in the portname doc. That doc also
discusses the utility of late-binding, which seems more trouble than
it's worth (sec 4.4).

> dstport that the NAT assigned).

It may work for the NAT (though I'm still not clear on that), but the
endpoint then needs to match the SYN/ACK to the original SYN too.

> hope you are too. (IAMACAHYAT)" option.

All it says is that dstport==0. If you want a clue-bit, use one of the
reserved header bits, please. It indicates clue in the protocol _and_
the designer, IMO ;-))

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 10 May 2006 09:27:24 -0700

> on the fly with TCP options in later round trips.

That's the problem - there are too many options that want to be in the
first RTT, including (e.g.) authentication, SACK, timestamp, and
windowscale (at a minimum) - not to mention portnames ;-)

Having a larger option space would be useful to that end. The
constraints of a new, larger option space would be like that designed in
portnames - positive ACK, with the suggestion that if it fails, a
backoff to the smaller option space is used.

> noticing the 16 bits of urgent pointer.

There's the rub - a feature you think is largely unused that can be used
for your purposes. Those tables turn fast, where your definition will be
redefined out from under you. Let's not do that, please. ;-)

> strings in the initial SYN.

See portnames ;-) Once you have a string, you can parse them however you
want.

>  1. "I can migrate this TCP connection to SCTP if you like."

Er, there's NO reason to use one protocol to negotiate another. Send two
SYNs and move on.

>  2. "I would like to establish shim6 state for this."

Seems like you need shim6 before the SYN can reach its dest. You're
trying to fold network state establishment with transport establishment.
While that's admirable from a latency viewpoint, it's a bit nonsensical IMO.

>       (which would be an implied HIP I1 message)

See #2, or at least that's what it seems like.

> was strictly legacy might be a good thing.

There's no reason to migrate to SCTP any more than there is to migrate
to DCCP (since many TCP apps don't actually need reliability). The
application gets to decide that.

Joe

---

From: Tim Shepard <[email-masked]>
Date: Wed, 10 May 2006 14:11:09 -0400

> into a protocol to negotiate which protocol to use. Right?

Sure, I think that's an OK way to think about it, with emphasis on the
word *eventually*.

> even if the app only knows TCP. No app code modification required.

Fine.  But it'd be nice to eliminate needless round-trip latencies.

Sending an old-TCP SYN and a new-fangled-TCP SYN in parallel seems
messy to me.  It'd be nice to find a way to succinctly say everything
that needs to be said in the first half of the first round trip time
in a single packet, and have the second half of the first round trip
time involve a single return packet.

Schemes involving DOS resistance often turn the original exchange
around so that the responder can be stateless.  (I first learned of
this sort of scheme in HIP, but there are other examples.)

So something which is both a plain old TCP SYN with an option saying
"If you do the more-modern-and-better thing, please initiate that
with me."  might be the right thing.    

The problem is that we've got a long list of candidates for what the
more-modern-and-better thing might be: BTNS, MOBIKE, SHIM6, HIP,
SCTP, etc... (and I apologize if I forgot to include your favorite
new-fangled end-to-end protocol).  I expect that for many years we
will have a list of contenders with more than one entry.

So maybe the initial option on the SYN should carry a bit vector or a
list of bytes indicating which new-fangled protocols are supported by
the initiator.

But I don't like how complicated this is getting.

			-Tim Shepard
			 [email-masked]

---

From: Tim Shepard <[email-masked]>
Date: Wed, 10 May 2006 14:26:14 -0400

> See portnames ;-) Once you have a string, you can parse them however you

I liked the portnames draft, except for the fact that the strings
would be constrained to be way too short.  (In the version of the
portnames draft that I read, you neglected the SackOK option which
reduces the possible length of the strings by another two bytes.)

> Er, there's NO reason to use one protocol to negotiate another. Send two

It may be simpler to send a single packet (with an advertisement of
willingness to do something else instead).

Off list someone proposed to me that a returning RST with options
carrying the beginnings of a turned-around 3-way handshake might be
done.  This avoids extra packets, avoids extra round trips, and avoids
extra state for connections that will be abandoned.

> Seems like you need shim6 before the SYN can reach its dest. 

Uh, no.   Have a look at how shim6 works.

> You're

I'm no layerist, and I'm unlikely ever to be converted to the layerist faith.
Latency matters.  Layerism is just dogma.

> See #2, or at least that's what it seems like.

Yep, it's similar to #2.

> application gets to decide that.

OK, maybe we still want a migrate-to-SCTP plan, even if it has to be
per-application protocol.

Which should we do first?  ssh over sctp?  XMPP over sctp?  http
over SCTP?

			-Tim Shepard
			 [email-masked]

---

From: Tim Shepard <[email-masked]>
Date: Wed, 10 May 2006 14:46:03 -0400

> discusses the utility of late-binding, which seems more trouble than

Some troubles with TCPMUX (RFC1078) are described in your portnames draft.

But I'm not proposing TCPMUX.

I'm proposing that the initial SYN carry a string in the data portion
of that SYN packet with dstport==0.  The reply can come back with a
port number filled in (which will work with cone NATs).  So now you
don't have the TCPMUX problems of a single port and all connections
succeeding.  (A RST could be returned if the contact name had nothing
listening.)

> endpoint then needs to match the SYN/ACK to the original SYN too.

With its original port number, and the ACK of its initial SYN (+
contact name string) and the IP addresses involved, it won't be
ambiguous).  If you're opening two different connections to the
same contact name at the same destination, you'll have to use
different srcport numbers.  That results in exactly the same
limitation we have today for how many concurrent connection
establishments to the same destination port that we can have
today.

> reserved header bits, please. It indicates clue in the protocol _and_

Actually, I prefer putting the IAMACAHYAT in a new 2-byte option
that goes with the SYNs.  A succesful exchange of IAMACAHYAT
would mean that the two TCP implementations both support a
well-defined list of future-proofing extensions/behaviors and
need not fear knocking the other end over with some weird option
or odd combination of lit-up control bits.

So maybe we should do that.

If we then *also* do a dstport==0 thing to allow for the initial
SYN to carry a contact name in the data portion of the packet,
then perhaps we could reclaim the space 2-byte option would use
by saying that IAMACAHYAT is implied if dstport==0 on the
initial SYN.  (And these two ideas can be considered seperately.)

			-Tim Shepard
			 [email-masked]

---

From: Mark Allman <[email-masked]>
Date: Wed, 10 May 2006 16:00:00 -0400

> mod that just extended the option space. 

I am going to pop up a level here.  This is some can I opened, isn't it?
Migrating from TCP to SCTP, using options echoed in RSTs as part of a
handshake, riding TCP on UDP, ..., man... I thought my hack was
sleazy---you guys have really outdone yourselves! :-)

In any case, about the above....  The way I look at it is this....

  + If the crystal ball says that for the forseeable future we're just
    going to add functionality to TCP (e.g., UTO or portnames or
    quick-start or a new authentication scheme or whatever) then maybe
    we just bite the bullet and extend the option space with some hack
    (and, all the proposals are) and leave the rest of the header alone.

  + If, on the other hand, the crystal ball says that in addition to
    *extensions* we're likely to need to augment the standard stuff
    (more port space, more sequence space, more reserved bits, even more
    window space, etc.) the we should either:

    (1) bite the bullet and say we have outgrown TCP and either:

      (1a) go about deprecating it in favor of SCTP/DCCP, or
      (1b) start the process of coming up with a next-generation
           byte-stream transport that includes more space and all the
           features a modern transport should have (whatever those are)

      or

    (2) decide that TCP is still a reasonable (if not optimal)
        general-purpose protocol and enact one hack to give it a bigger
        header such that it can accommodate today's networks and future
        expansion more readily.

I personally feel like I have heard enough noise about the smallness of
standard fields (and corresponding suggestions for how to fix each issue
independently) that I think the changes ought to be broader than simply
more option space.  I admit that this is more of a vibe than a
collection of hard evidence.  I am personally not in favor of replacing
standard fields with options that simply hold bigger values.  That seems
to me like it will just be a haphazard collection of hacks that will
make implementations more difficult, could cause NAT and firewalls to be
more complex (or, get confused and drop traffic), will complicate IDS
systems, etc.  I feel like a new byte-stream transport is probably
overkill and it'd take years to develop and even more years to
transition to.  So, for me, TCPx2 is really a quite pragmatic and
straightforward approach.  We increase TCP's belt size a bit, but pretty
much retain the logic of the protocol such that TCPx2 is straightforward
to implement and the transition path isn't too onerous.  (That is not to
say that all the TCPx2 details are right... just that I think the
approach seems about right.)

allman

---

From: Joe Touch <[email-masked]>
Date: Wed, 10 May 2006 13:11:02 -0700

Mark Allman wrote:
>     window space, etc.)

But the window scale option isn't more window space; it's a different
way of defining that field. Doubling the size of the field doesn't
accomplish the same thing; the shift count is 8-bits, which would
require a 255+16 bit field to be similar.

There isn't a good reason to expand the port number space per se; the
issue with port numbers is primarily one of mis-applied security.

We'll always benefit from more reserved bits, but the option space
accomplishes that.

IMO, the main issue is the lack of option space; we could use one
reserved bit to indicate the use of extended option space (I haven't
seen a proposal that does that, though).

Joe

---

From: Mark Allman <[email-masked]>
Date: Wed, 10 May 2006 16:12:11 -0400

> messy to me.  

It is.

> It'd be nice to find a way to succinctly say everything that needs to
> be said in the first half of the first round trip time in a single
> packet, and have the second half of the first round trip time involve
> a single return packet.

Yes, that's be nice.

Trouble is, I don't think it can be done.  Like I have said before,
we're not just testing the peer's abilities here.  We're also testing
the path's abilities.  If you send an old-TCP SYN and the peers agree
to something new there are absolutely no guarantees you can get the
new-fangled thing through the network.  If you send a new-style SYN and
it makes it to the peer and the peer doesn't understand then you're
going to have to retransmit with an old-style SYN.

Maybe I am missing something here, but it seems to me that hanging onto
this notion that we can negotiate some new header format (not just a new
option) using the old format is not going to work.

allman

---

From: Mark Allman <[email-masked]>
Date: Wed, 10 May 2006 16:27:09 -0400

> require a 255+16 bit field to be similar.

I have no idea what any of this means.  Of course WS is more window
space.  I just looked at RFC1323 to make sure I remembered it correctly
and it says that the maximum shift count is to be 14 -- which gives a
window of 2^30 bytes (1 GB).  Doubling the original 16-bit field to 32
bits gives a possible window size of 2^32 bytes (4 GB).  (And, as the
TCPx2 draft notes, someone suggested to me that a failed of the simple
*=2 rule on all fields is that it really isn't a doubling of the window
given the WS option and so maybe the advertised window field should be
more than doubled.  It's a reasonable point, I think.)

> issue with port numbers is primarily one of mis-applied security.

Not according to the IETF thread from a while back -- in which some were
claiming they had situations of the port size limiting things.  (And,
then I saw a private chat amongst a group of folks trying to figure out
if this was something to fix or not.)

> seen a proposal that does that, though).

So, you're in one of the camps I sketched.  I.e., you think the standard
fields are fine and all we need is room to grow new functionality.
That's fine.  

(I am not in that spot, but when you said yesterday that you generally
supported the TCPx2 I was worried that we might be agreeing too much
again! :-)  To me this is a little about crystal balls and it's not easy
to rationalize about some of these things, as I have noted before.)

allman

---

From: Joe Touch <[email-masked]>
Date: Wed, 10 May 2006 13:38:53 -0700

Mark Allman wrote:
> window of 2^30 bytes (1 GB).

Yup - sorry; I just saw 8 bits and extrapolated to even larger windows
from there. You're right - 32-bits is max.

> if this was something to fix or not.)

There are different issues:

	1. limitations of the reserved port numbers
	2. the need for more port numbers in general

The thread I saw focused on #1; that's a function of the number of
reserved ports, and whether there's a separation of system vs. user
reserved ports.

Increasing the port space isn't the solution; having a registry of sorts
that decouples the connection identifier from the application service
identifier is, and that's what the portname doc focuses on. If you just
want larger port spaces (and don't care about string names), just use
4-byte portnames and treat them as numbers.

> to rationalize about some of these things, as I have noted before.)

Agreed - like I said, I like this in general as an experiment, but think
that the thing we really _need_ (if we're going minimal) is more option
space. If we're fixing anything else, we're opening a can of worms.

Joe

---

From: Mark Allman <[email-masked]>
Date: Wed, 10 May 2006 22:49:53 -0400

> reserved ports, and whether there's a separation of system vs. user

What I have seen is "the lack of more than 16 bits is an issue"
... i.e., #2.  This is in the context of a big proxy of some sort.  I
need to crystalize this a bit more, I understand.  I will.

> If you just want larger port spaces (and don't care about string
> names), just use 4-byte portnames and treat them as numbers.

So, that's the sort of hack I am trying to avoid with TCPx2.  And, does
that even work?  The portnames are just initial, right?  They still have
to map into two 16-bit ports.  (But, we do open it up a bit by not
requiring one of them to be fixed, of course.)

> Agreed - like I said, I like this in general as an experiment, but
> think that the thing we really _need_ (if we're going minimal) is more
> option space. If we're fixing anything else, we're opening a can of
> worms.

I understand what you're saying.  I actually don't know that we *need*
anything.  As I have said before, we don't standardize new options at an
alarming rate.  

TCPx2 is not about a clear and present *need*.  What it is about is
trying to plan a little bit.  If we *need* one field to be extended and
we think there could well be more than we should do something more
general than an "I need this now" hack, IMO.  If we think there are
likely to be a bunch of fields we need to extend, even if we don't this
instant, then we should try a general approach, IMO.

allman

---

From: Joe Touch <[email-masked]>
Date: Thu, 11 May 2006 08:04:17 -0700

> need to crystalize this a bit more, I understand.  I will.

Making TCP's header bigger to support NATs is a mistake. As I said, they
create their own problems; they will continue to do so, regardless of
anything we do to help.

> requiring one of them to be fixed, of course.)

Port pairs - combined with IP addresses - determine the service
endpoints, and are still the connection ID. Portnames determine the
protocol. The portname is needed only to hand the connection off to the
service.

> instant, then we should try a general approach, IMO.

But a general approach opens a can of other worms too.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 11 May 2006 08:04:17 -0700

Joe

---

From: Mark Allman <[email-masked]>
Date: Thu, 11 May 2006 11:34:19 -0400

> Making TCP's header bigger to support NATs is a mistake. As I said,
> they create their own problems; they will continue to do so,
> regardless of anything we do to help.

Joe- don't make this just a religious NAT issue.  As you indicated in
you other email, you understand that is not the case.

> > trying to plan a little bit.  If we *need* one field to be extended
> > and we think there could well be more than we should do something
> > more general than an "I need this now" hack, IMO.  If we think there
> > are likely to be a bunch of fields we need to extend, even if we
> > don't this instant, then we should try a general approach, IMO.
> 

Please enumerate.  I am not saying x2 is without issue, but the can is
fairly scoped and small from my perspective.

allman

---

From: Joe Touch <[email-masked]>
Date: Thu, 11 May 2006 08:45:07 -0700

Mark Allman wrote:
...
> Your message was rejected

Between cooperating proxies, the solution to a lack of source port
numbers is to use persistent connections, i.e., fix the protocol.

...
> fairly scoped and small from my perspective.

1. is a double congestion window sufficient, or should it be 4x, i.e.,
to double what scaled windows already support?

2. how are the extra unused bits treated on receipt?
	if ignore, it's impossible to add a required flag
	(i.e., this is why 'required' is a flag on IPv6 options)

3. where is the version number?
I don't support _any_ new protocol that doesn't start with at least a
few bits so it can be changed without encumbering the layer above's
demuxing space.

4. if the option space is larger, and the header is larger, are the
option fields larger as well? or redefined?

--

The only reason to redo the entire header in one motion is that we hope
we won't come back to redo it; otherwise, we need to be backward
compatible (which admittedly this is not).

And what then about backward compatibility?

----

As an experimental protocol, this sounds fine. Let the market/public
decide. I guess I'm just arguing that it's premature to jump forward
with anything stronger than experimental - or was that what you were
going for?

Joe

---

From: Mark Allman <[email-masked]>
Date: Thu, 11 May 2006 12:21:01 -0400

> to double what scaled windows already support?

A detail to be worked out, as noted in the i-d and on the list.

> 	(i.e., this is why 'required' is a flag on IPv6 options)

They are the same as the remaining TCP bits today.

> few bits so it can be changed without encumbering the layer above's

This is the one bit of new logic that I am wondering about.  In general
I don't want to add any, but this bit of future proofing seems like it
could be useful and certainly in the spirit of "let's fix this in a
general way and not with N hacks".

> option fields larger as well? or redefined?

As proposed?  No change.  It's a valid question, however.

>> But a general approach opens a can of other worms too.

As far as I can tell, none of the above are worms caused by a general
approach.  They are all fine questions.  The draft is completely
preliminary and the IETF is for working through just these kinds of
questions.  But, just because something is not fully baked doesn't make
the trajectory wrong.

> The only reason to redo the entire header in one motion is that we
> hope we won't come back to redo it; otherwise, 

The reason for me is that we can do it pretty cleanly and easily and not
have to do N kludges to keep muddling by.

> we need to be backward compatible (which admittedly this is not).
> 

I don't even understand this comment.  What are you asking?  There is a
straightforward fallback.

> with anything stronger than experimental - or was that what you were

To tell you the truth this question never even crossed my mind.  This
started as a rockheaded idea and I figured it was not going to go
anywhere.  The more everyone on this list talks (about why we can work
around things without something like TCPx2) the more I think TCPx2
embodies the right approach.

But, since you asked ... For me there is no experiment in something like
this.  It is scoped so tightly that what would we learn from an
experiment?  Experimentals are specifically not really to be used in the
wild.  So, what experiment would you have a student perform in a lab?
I'm not saying you can't come up with something (e.g., something having
to do with the performance of a stack that supports multiple protocol
header types or something).  But, I don't think there is anything much
that we could come back to in 2 or 3 years and say "yeah, it worked" or
"no, it didn't".  So, for me, I'd throw it out at PS as the way to
extend TCP and that as people need "more" this is the way they get it
and that we're not going to give you more window space in another
"extended window scale" option or redefine the unused offset code points
to give you more option space or whatever.  And, then, as you note let
the market decide.

allman

---

From: Joe Touch <[email-masked]>
Date: Thu, 11 May 2006 09:50:33 -0700

Mark Allman wrote:
...
> questions.  But, just because something is not fully baked doesn't make

Agreed, completely. As I said in the beginning, I'm generally in favor
of going down this path... with the caveat below.

> straightforward fallback.

The fallback is dual-stack, isn't it? That's fine, but not quite what I
would expect for standards-track.

> wild. 

Not IMO. They're to gain more experience too. They're an indication that
we don't know yet whether this is the way to fix TCP.

> So, what experiment would you have a student perform in a lab?

First, let me know whether sending all 32 bits of the window space did
anything different from sending the shifted 16 top bits thereof ;-) (I
don't know congestion control as well as some on this list; it seems
like there might be an interaction lurking there, though).

---

From: Mark Allman <[email-masked]>
Date: Thu, 11 May 2006 13:23:43 -0400

I am purposely not addressing the experimental stuff.  Really way to
early to get into all that.

> > I don't even understand this comment.  What are you asking?  There
> > is a straightforward fallback.
> 
> The fallback is dual-stack, isn't it? That's fine, but not quite what
> I would expect for standards-track.

Yes, the fallback is "dual" stack.  Except that it isn't very dual.
I.e., except for the header construction / parsing it's pretty much the
same.  Don't read too much into that.  I don't mean to be overly glib.
But, it is very much the same protocol.

allman

---

From: Mark Allman <[email-masked]>
Date: Fri, 12 May 2006 10:35:25 -0400

> Well the TCPx2 endpoints would require more state. The initial window
> of data will be acked as TCP (not TCPx2) data. Even the though the
> sender has upgraded to TCPx2, it knows that the first window of data
> was sent with TCP, and thus accepts the acks for the initial window
> only.
> 
> bad. The main problem I see is security. It may become easy to hijack
> a connection.

But, how do you deal with the application?  If the connection asks for
some option that can only be done in TCPx2 and we fall into this weird
"we didn't use it at first but now we do" sort of state then how is that
communicated?

I guess I just keep coming back to the fact that we're not in a
synchronized state if two SYNs are in play.

> > But, it seems to me that this is roughly similar to just sending an
> > x2 SYN first and then a bit later sending TCP SYN.
> 
> Yes, similar... but not the same as waiting for the TCPx2 syn to
> timeout before sending a TCP syn.

I think it's all very similar, but you're right that there are
tradeoffs.  Two cases:

(1) Send a TCPx2 SYN, X msec later send a TCPx1 SYN if SYN+ACK has not
    come back.

(2) Send TCPx2 and TCPx1 SYNs together.  If the TCPx1 SYN+ACK comes in
    first, wait X msec before the connection continues to ensure the
    TCPx2 SYN+ACK will not come in.

These are not the same, but similar.  Basically, we delay for fallback
in both cases.

I don't have much preference for (1) or (2), but I'd like to
"synchronize" before we start sending data because I think any other
case is messy.

(And, I also like the idea of suggestion that hosts try to cache peer's
x1 vs. x2 abilities.  So, e.g., on subsequent HTTP connections this
dance is not needed.)

allman