Subject: [tcpm] TCP Four-Way Handshake

From: David Borman <[email-masked]>
Date: Tue, 14 Oct 2014 16:44:21 -0500

Hi,

I’ve just posted draft-borman-tcp4way-00.txt, which describes a 4-Way TCP handshake that is intended to allow the TCP EDO option to be used during the initial SYN exchange.  This was mentioned during the TCPM WG at the last IETF meeting.  Please see the draft for more details.

			-David Borman

---

From: John Leslie <[email-masked]>
Date: Wed, 15 Oct 2014 15:08:40 -0400

David Borman <[email-masked]> wrote:
> 
> I?ve just posted draft-borman-tcp4way-00.txt, which describes a
> 4-Way TCP handshake that is intended to allow the TCP EDO option
> to be used during the initial SYN exchange. This was mentioned
> during the TCPM WG at the last IETF meeting. Please see the draft
> for more details.

   Thanks for this draft!

   I wanted to read it twice before responding -- and I'm still not
ready to discuss it at length...

   I have (so far) one comment and one question for David.

   The comment:
The draft proposed allocating one of the three remaining Reserved bits
in the TCP header; but Appendix B says this is not necessary to the
proposal.

   Intuitively, I feel that to allocate one of the Reserved bits would
need to be justified by something more than expanding option space.
Are there any other uses of the four-way-handshake envisioned?

   The question:
David notes the simultaneous-open case in his introduction; but I
don't follow how simultaneous-open would resolve in this proposal.
Clearly, simultaneous-open, however rare, could still happen...

--
John Leslie <[email-masked]>

---

From: David Borman <[email-masked]>
Date: Wed, 15 Oct 2014 14:51:44 -0500

> in the TCP header; but Appendix B says this is not necessary to the

What I meant was using a reserved bit wasn’t the only way to indicate
support for the four-way handshake.  It can also be achieved via a new
explicit 4WAY TCP option, or implied support by the presence of some
other TCP option, such as EDO.  Any of the methods would work.  I chose
to pick one method for the main body of the document, and present the
alternatives in Appendix B.

> Are there any other uses of the four-way-handshake envisioned?

It provides a general mechanism to allow the connection initiator
a second chance during the SYN exchange, based on responses from
the server.  The EDO case is a concrete example, where the initiator
couldn’t put in all the options they wanted to include in the
initial exchange due to the limited size of the option space.

It’s interesting to note that EDO is actually a new version of the
TCP header, and it’s not the first; the Window Scale option also
created a new version of the TCP header.  Most of the attempts at
expanding the option space are working very hard at hiding this
fact, in the name of backwards compatibility and getting through
middle boxes.

While the four-way handshake would be used for EDO support in
the SYN exchange, it is not limited to just EDO.  It can be used
for any TCP modification where you would have done something
different in the initial SYN had you known that the other side
understood the modification.  But the ironic part is that once
you have EDO, you have the ability to put just about anything
into the initial SYN by putting it into an option.  It’d be
trivial to switch to an entirely new TCP header layout by including
the new layout in a TCP option, something you just can’t do
today because of the limited initial option space.

I chose to start with recommending using a reserved bit because
then it isn’t using up even more option space, which matters most
when talking to legacy TCP implementations, and it doesn’t
explicitly tie it to the EDO option.

> Clearly, simultaneous-open, however rare, could still happen…

Ah, the simultaneous open was my inspiration for the 4-way handshake.
It also has a 4 packet exchange, crossing SYNs and then crossing
SYN/ACKs.  In the simultaneous-open case, the state transitions
when viewed by one side are:
    CLOSED -> SYN-SENT -> SYN-RCVD -> ESTABLISHED.
With the 4-way handshake, the initiator makes the same transitions:
    CLOSED -> SYN-SENT -> SYN-RCVD -> ESTABLISHED.

That’s why I originally envisioned the first response being a
bare SYN, which would make it look on the wire even more like
a simultaneous open.  But however elegant that might seem, I
think it is a non-starter because of middle boxes that would
probably block the returning bare SYN.

		-David

---

From: Joe Touch <[email-masked]>
Date: Thu, 16 Oct 2014 15:34:11 -0700

On 10/14/2014 2:44 PM, David Borman wrote:
> I’ve just posted draft-borman-tcp4way-00.txt

Some comments below.

Joe

> The TCP packet format has 54 bytes for adding TCP options

TCP currently has only 40 bytes of option space, not 54
	the DO can be 0..15 in 4-byte words
	that's 0 to 60 bytes of header, including the default 20
	which leaves 40 for options

	(reserved bits or other redefined header fields are not
	options; IMO, options are the fields with a given
	structure as defined in RFC793)

> If both sides send and receive a given option in a
>    packet with the SYN bit set, then both sides know that the option is
>    supported.

In current TCP, new options are indicated in the bare SYN and confirmed
in the SYN-ACK. The above isn't explicit in how this exchange happens.

-----

We've already discussed the latency impact for the initial
client->server request, i.e., one additional RTT.

I'm not sure I agree with the claims here about option directionality;
it overlooks the fact that current TCP allows the client to decide what
options to use on a given connection, subsetted by what the server
accepts. For that to happen here, you need a lot more text in how option
processing is radically different during 4WHS:

	- this still needs extended space in the server->client SYN,
	and since you haven't tested EDO in both directions you can't
	assume it will pass without silent asymmetric removal (see
	below); if you don't have that space, you're back where you
	started from because you'd need a 5WHS at least.

	- the options offered by the server need to be ALL POSSIBLE
	options the client may want to activate, which could be
	large even without variation

	- the client still needs to be able to be the one to decide
	which options are used IMO, which means you still have a
	problem with going to ESTABLISHED before you do a TWHS on
	the options *actually used*

		e.g., what if:

			the client wants A, B, C

			the server offers A,B,C,D,E,F,G
			but can't do A,B,C together

			the client picks A,B,C for the SYN/ACK
			but the server would have to terminate
			the connection and the client may have
			accepted data on an invalid connection

As noted in the discussion of EDO during SYN/ACK, *if* we believe there
are middleboxes that might silently drop EDO asymmetrically BUT ALSO
allow TCP to pass asymmetrically, then we can't rely on EDO to extend
space in the SYN/ACK.

----

---

From: David Borman <[email-masked]>
Date: Fri, 17 Oct 2014 11:29:36 -0500

> TCP currently has only 40 bytes of option space, not 54
...

Yep, pilot error, of course there are only 40 bytes for TCP options.

> in the SYN-ACK. The above isn't explicit in how this exchange happens.

To enable use of a TCP option, both sides have to agree to use
it.  The convention has been that this is done by sending and
receiving the option during the 3-way handshake in packets with
the SYN bit set.  An optimization of that is that there is no
point in putting the option into the SYN-ACK if it wasn’t received
in the SYN.  But the underlying rule is that you have to both
send and receive the option in a packet with the SYN bit set
to enable the option, irrespective of the ACK bit.  In the case
of a simultaneous open, the presence of the option in both SYNs
is sufficient to indicate support on both sides, even before the
SYN-ACKs are exchanged.

With the 4-way handshake and EDO, the client has a second
chance to enable TCP options via its SYN-ACK, so there is then
value in the first SYN-ACK from the server to include additional
TCP options that were not included in the initial SYN from the
client.

> client->server request, i.e., one additional RTT.

Actually, only 1/2 RTT overall, and for delivery of data
to the application, either 0 or 1 RTT depending on which
side of the connection you are on and whether or not you
put data into the SYN or SYN/ACK packets.  That’s why I
put all the examples in the document.

> options to use on a given connection, subsetted by what the server

See my comments above, these are all conventions with each individual
TCP option defining how they are enabled an used.  There is no reason
that every TCP option has to continue to follow that model.  Its
biggest advantage is that packets with SYN are reliably transmitted
at a fixed point in the sequence space,  so you don’t have to create
a whole new option negotiation mechanism.  And I’ll argue that it’s
the intersection of the options offered by both the client and the
server in their SYN packets; not including options in the SYN-ACK
that weren’t present in the SYN is just an optimization.

> 			accepted data on an invalid connection

This is a rat-hole not worth going down.  Don’t forget about
the existing simultaneous open case, which is not the 3way
handshake.  I know that it’s a rare case, but it is still part
of TCP and has to be considered.  Each TCP option has to be defined
for how it operates, including enablement, so talking about how
fictional options might be ill-defined isn’t very useful.

> allow TCP to pass asymmetrically, then we can't rely on EDO to extend

That really feels like the tail wagging the dog.  Unfortunately middle
boxes are a reality, but we have to be reasonable about how far we are
willing to go to accommodate their whims, and this asymmetrical argument
is going too far in my mind.

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

---

From: Joe Touch <[email-masked]>
Date: Fri, 17 Oct 2014 10:49:59 -0700

>>> I’ve just posted draft-borman-tcp4way-00.txt

Cutting to the key issue, IMO.

...
...
> This is a rat-hole not worth going down.
>... so talking about how

Here's a view from that fictional rat-hole:

	Client SYN indicates options that fill 40B...

		Server sends SYN with responses for those options,
		and uses the extension space to indicates other
		options it hasn't seen that it supports.
		In this case let's say it's:
			TCP-MD5
			TCP-AO
			MPTCP

At this point, you have a TCP that has offered three options that are
NOT compatible with each other. TCP-AO is "MUST NOT" with TCP-MD5, and
TCP-MD5 isn't compatible with MPTCP.

So the client is now being offered a set of options that don't make sense.

Note that although simultaneous opens may happen, there's no rule that
requires the connection to unify the options offered in the two SYNs AFAICT.

> is going too far in my mind.

I agree, but the SYN/ACK is the only segment with this issue *if* we
require EDO in all segments once negotiated.

Joe

---

From: David Borman <[email-masked]>
Date: Fri, 17 Oct 2014 13:43:25 -0500

> On Oct 17, 2014, at 12:49 PM, Joe Touch <[email-masked]> wrote:
> 

It only doesn’t make sense if you try to use them all at the same
time, which would be silly.  So I don’t see what the problem is, the
client only responds to one of those options, and ignores the others.

All this really points out is that when there are incompatible options,
there should be a documented procedure for how to handle the case when
they are all negotiated.  This case would be easy, if TCP-AO is negotiated,
then TCP-MD5 and MPTCP must be ignored.  If TCPM-MD5 is negotiated, MPTCP
must be ignored.  Then you are handling the simultaneous-open case today where
both sides indicate in their initial SYNs that they support all 3 options.

Not putting options into the SYN-ACK that weren’t in the SYN should be
viewed as no more than an optimization, and not a hard and fast rule,
it should be harmless to put other options into the SYN-ACK, just not
as efficient with the tight option space.

			-David

---

From: Joe Touch <[email-masked]>
Date: Fri, 17 Oct 2014 15:29:39 -0700

On 10/17/2014 11:43 AM, David Borman wrote:
> they are all negotiated. 

Currently:
	SYN indicates desired options
	SYN/ACK indicates subset of desired options
	ACK indicates final set negotiated

Right now, one side can easily avoid that by what it selects in its SYN.
You're suggesting entirely different semantics for options that now need
to be determined for all past and future options concurrently.

I don't think that's feasible.

Joe

---

From: David Borman <[email-masked]>
Date: Fri, 17 Oct 2014 17:56:40 -0500

> On Oct 17, 2014, at 5:29 PM, Joe Touch <[email-masked]> wrote:
> 
> 
> 

You keep missing the point.  If an option isn’t both sent and received
in a packet with the SYN bit, it is not enabled.  So with the 3WHS it
doesn’t matter if there are additional options in the SYN-ACK, they will not be
enabled because they weren’t in the original SYN.  The fact that the SYN-ACK
is a subset of what was in the SYN *is only an optimization*.  The final ACK
has nothing to do with it, it’s only what is exchanged in the packets with
the SYN bit that matter.

Look at RFC1072, supported options were sent in any packet with the SYN
bit set, so the SYN-ACK would have WS even if the inbound SYN didn’t have
it.  I’m the one that pointed out because you had to both send and receive
the option to enable it, that sending the option in the SYN-ACK when it
wasn’t received in the SYN wasn’t useful, and that’s why RFC1323 added
that you only sent the options in the SYN-ACK if they were received in
the SYN.  But it was purely an optimization.  With the 3WHS, all TCP
implementations should ignore any options in the received SYN-ACK that
they didn’t send in the initial SYN.  If they don’t, they are broken.

With the 4WHS, the client has a second chance to enable additional options
with its SYN-ACK, provided they were received in the servers SYN-ACK.
		
	-David

---

From: Joe Touch <[email-masked]>
Date: Fri, 17 Oct 2014 16:29:35 -0700

On 10/17/2014 3:56 PM, David Borman wrote:
> in a packet with the SYN bit, it is not enabled. 
...
> With the 3WHS, all TCP

So:

	- in 3WHS, the SYN-ACK cannot add new options

	- in 4WHS, the SYN-ACK can

In 3WHS, the SYN is where all new options happen and are confirmed using
a 3WHS.

If 4WHS adds new options in the SYN-ACK, it needs another message to
complete a 3WHS based on the options selected for a given connection.

I.e., the client adds new options during SYN-ACK, the server confirms
what it selects as a subset in the ACK to the client - but the client
might still not like the subset picked. It needs a message to confirm
that final choice.

JOe

---

From: David Borman <[email-masked]>
Date: Fri, 17 Oct 2014 21:23:19 -0500

> On Oct 17, 2014, at 6:29 PM, Joe Touch <[email-masked]> wrote:
> 
> 
> 

The SYN-ACK can contain new options, they just won’t get enabled,
since they weren’t received in the SYN.  It is an optimization to
exclude from the SYN-ACK options that can’t be enabled.

> In 3WHS, the SYN is where all new options happen and are confirmed using

Again, both sides propose what options they can support, and they enable
the intersection of what they sent in their SYN, and received in the
other sides SYN or SYN-ACK.  It is only an optimization that the SYN-ACK
doesn’t need to include options that it already knows will never be enabled
for this connection, since they weren’t received in the SYN.

Both sides only enable the intersection of options that were both sent
and received in a packet with the SYN bit set.

Let me make it clearer with the simultaneous open:  In that case, both
sides send a SYN packet with some set of options.  When they each receive
each others SYN, they both now have the intersection of options both sent
and received in a packet with a SYN, and know what options are enabled.
What’s in the SYN-ACK that they then send is superfluous, both sides
have already determined what options are supported for this connection.

> might still not like the subset picked. It needs a message to confirm

The final ACK doesn’t have any part of the option negotiation, in either
the 3way or 4way handshake.

Again, any option that is both sent and received in a packet with the
SYN bit set enables the option.  With the 4way handshake the client
sends two packets with the SYN bit, so if the server has included
additional options in its SYN-ACK that weren’t received in the SYN,
then the client can enable those options by including them in its
SYN-ACK.  That is the whole point of the 4way handshake, that with
the EDO option it allows more options to be enabled than will fit in
the initial SYN which has limited option space.

			-David

---

From: Joe Touch <[email-masked]>
Date: Mon, 20 Oct 2014 15:58:44 -0700

On 10/17/2014 7:23 PM, David Borman wrote:
...
> since they weren’t received in the SYN.

"Add" was ambiguous; I had intended "offer and enable". Yes, they can be
offered but won't be enabled.

...
> other sides SYN or SYN-ACK. 

There are four messages:
	X-SYN		Y-SYN		
		
	X-SYN/ACK	Y-SYN/ACK

Presumably, the intersection will be of the options in the SYNs but
there are options that don't discuss the case of receiving a SYN while
in SYN-SENT as a separate case. They merely talk about reacting to the
SYN/ACK seen.

> It is only an optimization that the SYN-ACK

I understand your logic but I'm not convinced that all options are
defined to work that way.

> the 3way or 4way handshake.

Again, we'd have to check the definition of every option to ensure
that's the case. Strictly, the SYN can offer a set, the SYN/ACK can
offer a subset back, and the ACK can turn on a subset of those indicated
in the SYN/ACK. I don't know if any option takes advantage of that
sequence, though.

> SYN bit set enables the option. 

Offers the option. Options are offered then confirmed.

> With the 4way handshake the client
> SYN-ACK.  

The client offers a set of options in the SYN

The server responds with a SYN:
	- does it confirm any of those options yet?
	- what other options does it send?
		it needs to send all the options it *can support*
		because it doesn't know which ones the client
		wants to enable, but not all those combinations may
		be desirable by the server
	
The client sends the SYN/ACK:
	This message is supposed to complete the set selected

TCP does support simultaneous open, but not all options are necessarily
defined as supporting that.

As per above, the server SYN isn't like any other SYN. It doesn't
contain the options the server enables for the connection because that's
not how servers typically work. It has to contain all the options that
COULD be used on a connection, but it's entirely possible there are sets
that don't make sense.

The server has to have a chance to decide that the final set negotiated
isn't what it wanted. It gets that chance when it decides to open a
connection or when it responds to the whole set of options offered - but
neither happens in this case.

Again, I conclude that this is missing at least one more message, if not
another entire phase of handshake.

Joe

---

From: David Borman <[email-masked]>
Date: Tue, 21 Oct 2014 11:56:09 -0500

> On Oct 20, 2014, at 5:58 PM, Joe Touch <[email-masked]> wrote:
> 

No.  For example, look at 7323, it is very explicit that it is sending
and receiving the option in a packet with the SYN bit set that enables
it, it makes no distinction between a SYN-only and a SYN/ACK packet.  It
also has the added optimization that there is no need to include
the option in a SYN/ACK if it wasn’t received in the inbound SYN, since
it can never be enabled.  It is the presence of the option in a packet
with the SYN bit that matters, and that works for both the 3WHS and the
simultaneous open.

...
> defined to work that way.

They aren’t.  I’m sorry if you thought I was saying that all TCP options
were negotiated this way.  Each option definition describes if/how it is
negotiated.  The method in RFC 7323 is to exchange the options in packets
with the SYN bit set.  For options so defined, the 4WHS gives an opportunity
to enable additional options that didn’t fit into the initial SYN-only packet.

> in the SYN/ACK. I don't know if any option takes advantage of that

Strictly, for these type of negotiated options, it is the presence
of the option in packets with the SYN bit set that matter, not whether
it is a SYN-only or SYN/ACK packet.  It is sending and receiving the
option in a packet with the SYN bit set that enables use of that option.
Packets with the SYN bit are reliably delivered, ACK-only packets are not.

...

> The server responds with a SYN:
SYN/ACK in the 4WHS

> 		be desirable by the server

It includes any additional options that it makes sense to include,
making use of the additional space provided by the EDO option.
Nothing says it has to include everything.  It doesn’t have to
include things that don’t make sense, such a uni-directional
options.

...

For options that are negotiated in the SYN exchange, the servers SYN/ACK
in the 4WHS should only contain additional options if it is willing to
enable them.  Hence if something is non-sensical, it shouldn’t include
them.  There is no requirement that the servers SYN/ACK contain every
option that it knows about.

The 4WHS is about providing an *opportunity* to enable additional options
that didn’t fit into the initial SYN-only packet, not a *requirement* that
the servers SYN/ACK has to contain all known additional options.

		-David

---

From: Joe Touch <[email-masked]>
Date: Tue, 21 Oct 2014 10:47:28 -0700

On 10/21/2014 9:56 AM, David Borman wrote:
> it, it makes no distinction between a SYN-only and a SYN/ACK packet.

Not all options are specified that way.

> to enable additional options that didn’t fit into the initial SYN-only packet.

You're thus proposing NEW requirements on option negotiation, and that
ought to be clear in your document as well as considered in comparison
to all existing and pending options.

...
> include things that don’t make sense, such a uni-directional

But it has to include *anything* that the client might want to ACK.
I.e., your proposal is NOT consistent with current semantics of option
use in SYN segments.

Right now, IMO:
	- options offered in SYNs are those actually desired for
	a given connection

	- options in the SYN/ACK confirm the subset of those
	desired options

You're proposing that options in the server's SYN be "a superset of
those the client may want to enable on this connection".

...
> the servers SYN/ACK has to contain all known additional options.

It's the Server's SYN that has this property.

---

From: David Borman <[email-masked]>
Date: Tue, 21 Oct 2014 13:50:49 -0500

> On Oct 21, 2014, at 12:47 PM, Joe Touch <[email-masked]> wrote:
...
> to all existing and pending options.

What new requirements?  It’s an extension that allows for options that
didn’t fit into the initial SYN to still be enabled, by including them
in the exchanged SYN/ACK packets.

> But it has to include *anything* that the client might want to ACK.

No it doesn’t.  It would only include options that it would still
like to be enabled, but weren’t included in the inbound SYN.  Why
on earth would it offer up to enable options it doesn’t want to use?

> 	- options in the SYN/ACK confirm the subset of those

Yes, that is your opinion, but it is wrong.  As documented in
RFC 7323 and others, it is the sending and receiving of the option
in packets with the SYN bit set that enables use of the option,
e.g. Window Scale, Timestamps, SACK permitted.  In the 3WHS, the
options in the SYN are the options the client would like to be
enabled, the options in the SYN/ACK are the options the server
would like to be enabled.  Both sides only enable the options
that they both sent and received in a packet with the SYN bit set.

For options that are enabled via this mechanism, it is only an
optimization to not include in the SYN/ACK any option that was
not received in the SYN, since it can never be enabled using the
3WHS.  There is no restriction that a SYN/ACK can’t include TCP
options that weren’t included in the SYN.

> those the client may want to enable on this connection”.

In the 4WAY handshake, yes, the servers SYN/ACK can make use of
the EDO option and include additional options that it would like
to enable for the connection.  It isn’t strictly a superset, because
the server wouldn’t include options from the inbound SYN that it doesn’t
understand or want to enable.  If it includes additional options in
the SYN/ACK, and the returning client’s SYN/ACK also has those options,
then they are enabled, even though they weren’t present in the original
SYN.
 
> It's the Server's SYN that has this property.

You keep saying “Server’s SYN”.  Do you mean “SYN-only” packet?  That’s
only in a simultaneous open.  As currently documented, in the 4WAY
handshake the server responds to the inbound SYN-only with a SYN-ACK,
not a SYN-only packet.

And the property is that if each side sends and receives an option in a packet
with the SYN bit set, then the option is enabled; it’s the same for 3WHS and
4WHS.

			-David

---

From: Joe Touch <[email-masked]>
Date: Tue, 21 Oct 2014 13:09:11 -0700

...
> What new requirements? 

That options be negotiated exclusively by appearance in the SYN in each
direction.

> on earth would it offer up to enable options it doesn’t want to use?

It has to send all the options that might be coming in the client's
SYN/ACK. It has to read minds or be exhaustive.

> e.g. Window Scale, Timestamps, SACK permitted. 

You've already admitted that all options aren't specified that way.

> In the 3WHS, the
> enabled, 

Agreed...

> the options in the SYN/ACK are the options the server
> would like to be enabled. 

Agreed.

But in the 4WHS case, the client SYN and SYN/ACK have that property, but
the server SYN/ACK has to include options the server supports that the
client MIGHT want to enable.

That's a significant change in semantics.

...
> understand or want to enable.

But it has to include ALL options it can support that the client MIGHT
want to enable because it hasn't seen the client's SYN/ACK, so it (the
server) doesn't know what options it might need to be agreeing to.

---

I agree that the net result is the same (only the options that both
sides want are enabled), and that the typical result is the same (only
the options the client actually wants are suggested.

But the server SYN has to be comprehensive - it has to include every
option that this connection MIGHT support.

> You keep saying “Server’s SYN”.  Do you mean “SYN-only” packet? 

No - I meant the only SYN packet the server sends (the SYN/ACK in the
more typical case).

...
> with the SYN bit set, then the option is enabled; it’s the same for 3WHS and

Yes, but - as I thought you agreed in the last message - that's NOT a
requirement of all options as currently designed.

Joe

---

From: David Borman <[email-masked]>
Date: Tue, 21 Oct 2014 15:55:31 -0500

> On Oct 21, 2014, at 3:09 PM, Joe Touch <[email-masked]> wrote:

You're reading things that aren’t there.  There is no one mechanism for
enabling use of TCP options.  Each option defines for itself how it is
to be used, including any enablement.  For many existing options, enablement
is defined as the option being present in both a packet sent and received
with the SYN bit.  Examples include Window Scale, Timestamps, and SACK Permitted.

That is nothing new, and is not a requirement for any other TCP option.

...
...

Absolutely not.

In the 4WHS, for options that are only enabled by their presence in the
SYN exchange, the servers SYN/ACK can contain additional options to allow
the client to agree to enable them by including them in it’s SYN/ACK.
That’s it.  End of story.  If the initial SYN didn’t include Timestamps
but SYN/ACK from the server did include Timestamps, then if SYN/ACK from
the client includes Timestamps, Timestamps are enabled.  The server
doesn’t have to know anything about what additional options the client
might or might not like to enable, it only has to know what additional
options *it* would like to enable.

		-David

---

From: Joe Touch <[email-masked]>
Date: Tue, 21 Oct 2014 14:02:51 -0700

On 10/21/2014 1:55 PM, David Borman wrote:
> enabling use of TCP options.

That is my primary point.

>  Each option defines for itself how it is

4WHS won't work when options are not defined as being enabled by the
option being present in both SYN segments of a 3WHS.

> That’s it.  End of story. 

Again:

#1	Client sends SYN with A, B ->

#2				<- Server sends SYN/ACK
				with what? it can send A,B
				what else?

#3	Client sends SYN/ACK with X,Y->

#4				<- server, never having seen X or Y
				MUST have had to send X AND Y in
				its SYN/ACK

If all options are enabled by occurring in a SYN in both directions, we
have to also note that #2 is the only SYN(ACK) the server sends.

#2 SYN/ACK has to anticipate the options sent in #3 client SYN/ACK.

How exactly does it do that? Doesn't it have to send ANY option that
MIGHT be arriving in the client SYN/ACK - but it has to do that BEFORE
the client sends it.

Joe

---

From: David Borman <[email-masked]>
Date: Tue, 21 Oct 2014 16:46:38 -0500

> On Oct 21, 2014, at 4:02 PM, Joe Touch <[email-masked]> wrote:
...
> option being present in both SYN segments of a 3WHS.

Options that don’t have the limitation that they have to be exchanged
in the initial SYN exchange probably aren’t affected by the lack of option
space in the initial SYN.

The only options that don’t work with the second-chance enablement
that the 4WHS allows are those options that are unidirectional from
the client, for example the CC option in T/TCP.

...
> #2 SYN/ACK has to anticipate the options sent in #3 client SYN/ACK.

And that’s where I disagree.  The server is *not* trying to anticipate
what the *client* might send in the #3 SYN/ACK.  The additional options
in #2 server SYN/ACK are options that the *server* would like to enable
that weren’t present in the #1 client SYN.  The client can then agree
to enable some, all or none of them with the #3 SYN/ACK.

If one uses your offer/confirm terminology, then #1 offers one
set of options.  #2 confirms some, all or none of those options,
and also offers a second set of options.  #3 confirms some, all
or none of the second set of options.

> MIGHT be arriving in the client SYN/ACK - but it has to do that BEFORE

The server doesn’t know or care what the client couldn’t put into
the initial SYN.  It only knows what options were missing from the
initial SYN that it would like to have enabled, and that’s what it
adds to the #2 SYN/ACK.

		-David

---

From: Joe Touch <[email-masked]>
Date: Tue, 21 Oct 2014 16:42:05 -0700

On 10/21/2014 2:46 PM, David Borman wrote:
...
> to enable some, all or none of them with the #3 SYN/ACK.

In that case, what happens with X,Y?

They can't be confirmed in #2 because the server doesn't know they're
desired yet, but the server might support them *IF* the client wants
them, but might not have turned them on if it were to have initiated the
connection.

E.g., what if the server supports both TCP-MD5 and TCP-AO, but the
client supports only one of those and it didn't fit in the #1 SYN? The
server can't know which one to put in the #2 SYN/ACK but it's also
prohibited from putting in both.

However, if it doesn't put in either one, then neither MD5 nor AO will
be successfully negotiated as active on the connection.

Joe

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 21 Oct 2014 21:34:26 -0700

Hi David,

(as an individual of course..)
I personally like this idea from the following reasons.

1: use SYN-ACK to initiate feature negotiation (as discussed in the
previous thread)

2: it can expand SYN options space to 80 octets without overriding DO
field. It might be more middlebox friendly.

3: we might be able to re-design syn cookie solution that can address the
previous issues.

4: even if an option in SYN/ACK has been removed by middleboxes, it can
reliably find this situation.

5: in mptcp, initiating subflow requires 4 packet exchanges. With 4-way
handshake mechanism, we might be able to do this with non-mptcp-specific
way.

6: similar to 5, it might be useful some secure negotiations where we don't
want to put something that requires computations in SYN, but want to
perform some cryptic algorithms in later packet exchanges.

(as one of co-chairs..)

When you submit new version, please include -tcpm- in the draft's name so
that we can track it easily.

Regards,
--
Yoshi

On Tue, Oct 14, 2014 at 2:44 PM, David Borman <[email-masked]> wrote:

> Hi,
>
> I’ve just posted draft-borman-tcp4way-00.txt, which describes a 4-Way TCP
> handshake that is intended to allow the TCP EDO option to be used during
> the initial SYN exchange.  This was mentioned during the TCPM WG at the
> last IETF meeting.  Please see the draft for more details.
>
>                         -David Borman